> Sophisticated package management can be a very nice convenience, but many
> people presume that having all this comes for free. There is a cost
> associated with getting all your packages to just come together like that.
>
> 1) Often times, the package may not match the vanilla documentation that
> is available for that package, making it a little more difficult to use,
> since you have to keep in mind the local tweaks that were made.
This is coupled with the other side of this issue: Sometimes packages
do not follow established Linux standards -- like the Linux File-system
Standard. I cringe any time I see an application want to install itself
in /usr/local/<app_name>. That's just not how /usr/local is supposed
to be used. (The structure of /usr/local is supposed to mirror that of
/usr.)
If your expectations are package-specific, you'll be looking for things
in different places than Linux-standard locations. Yes, it means that
when you read the package-specific documents things will be in different
places than on your system, however these locations are consistent
for all products on your system, and within very little time you come
to expect things to be in the right (for Linux -- not the product)
location.
> 2) Doing this modification requires a good deal of effort, so you end
> up with version lag. This is especially pronounced on Debian.
Debian is trying hard to reduce this in the future. See
http://www.debian.org/News/2009/20090729 "Debian decides to adopt
time-based release freezes".
The DEB-style package management is much less arduous than the
RPM-style. This is related simply to the complexity of the package
specifications for each.
The big problem with Debian was historically the vast majority of
the user community were using something other than the latest stable
release. Outsiders only looked at the stable release. Insiders paid no
attention to the stable release, only using the "unstable" release. Due
to so many people using the "unstable" release, people became unwilling
to update the packages as frequently, worried that they'd break things
for people. Debian has since adopted an "experimental" release to take
over the role of what used to be handled by "unstable". My understanding
is that this has eased the issue.
> 3) The benefits you list above come as the result of careful
> packaging, not really as an innate feature of a package system. The
> package system provides for this, but doesn't actually do this for
> you. When dealing with distributions that try to stay more up-to-date
> with the latest package versions, you see more mistakes and less
> stability.
That is true, careful packaging is typically important. I think of DEB
packages as being easy to create non-compliant packages. (That is, it is
easy to Debian-ize a package, but it takes some knowledge/work to get it
policy-compliant.)
If you check out the system used by Foresight Linux it really looks
designed for the bleeding edge. It merges configuration changes
between what ships with the package with the user-supplied changes
without the simplicity of the DEB-based system. (I've heard that some
RPM-based systems over-write user-edited configuration files without any
user-interaction!)
More interesting, with Foresight Linux you can roll-back any package
update back to the point you initially installed the system from CD.
I've heard that when the RedHat developers present new open-source
packages to their local Linux User-Group, before the meeting is over
one of the Foresight people will have downloaded the source, created a
Foresight package, uploaded it to the repository for folks to get, and
it will be available for anyone to use. It's explicitly designed as a
package management system with very little overhead to creating new
packages.
> In short, I am not arguing that these are terrible systems and that
> everyone should use Slackware's basic tools (many Slackware users
> use an apt-get like equivalent), but we should be aware of the costs
> associated with the benefits that a fairly complex system like
> Debian's provides. Fortunately, in the Linux world, there is choice in
> whether you want to manage things a la Slackware, or a la Debian, and
> there are multiple distributions based around each; it's just good to
> know what you get and what it costs to use each.
My first Linux distribution was Slackware -- back in 1995. My father
bought me a book (containing free/open-source docs) that included a
Slackware CD. I'm sure it wasn't even the then-current Slackware, but it
got me hooked (on Linux, if not on Slackware).
Slackware is definitely one of those distros that a person should try
just to see how it is similar/different than the others. It is really
significantly different than the others.
Cheers,
Steven Black
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
No comments:
Post a Comment