Is It Time To Change RPM?

Floris pointed us to an excellent article over at Freshmeat discussing the problems with RPM. It compares RPM to the other alternatives (mainly Debian's apt system) and discusses where the problems are. It's not a distribution war thing, this is a serious problem that needs discussing. Read the story and chime in.

Re:Problems with ports

Firstly, it's not easy to update the ports tree itself

You're going about it the wrong way there. Have a look see at the FreeBSD Handbook for CVSup [freebsd.org] for more details on this. Also, if you don't already have a copy, go pick up "The Complete FreeBSD" [fatbrain.com] from Walnut Creek. It's an outstanding book, and one that I found to be a much easier read than many of the Linux specific books out there. It has a chapter covering the ports tree that I think you'd benefit from.

Mind you, ports do have their problems. All in all, I think that it's a far better approach to software distribution than anything else that I've seen. A more in depth discussion of this, which even relates to this thread, was done a few weeks back right here on Slashdot, "Unified BSD packaging system?" [slashdot.org]. One of the concepts brought up in that discussion I haven't seen mentioned in this one is if there is some way to unify all the *nix world rather than just the various flavors of Linux.

It sure would be cool to see a group work out the best of the best features from the leading methods of distributing software and bring it to all the platforms. Definitely not holding my breath for anyone to actually do this, just a pleasent thought just the same.

The problem with RPM is uptodate documentation!

In my opinion, the problem with RPM is that the documentation is falling behind. The book 'Maximum RPM' is of very good quality but it hasn't been updated since RPM 2.0 days really and so many things have changed or features have been added. For example, the relocatable packaging feature has been greatly improved. Macros and triggers have been added. The latest RPM can do automatic gzip or documentation, strip binaries and do additional checks. All this leads to RPMS of varying quality because they come from various sources, each with differing opinions and standards. If you want to see how bad it is, just use the program 'rpmlint' or a typical RPM package and see all the warnings it gives you.

Re:Packaging is just plain dumb

Where you do bring up some good points here, the basic concept of what you're talking about just isn't desirable. Let's work through your example, which is a fair one to be sure.

On the destkop, a user who, on Christmas morning, getting messages that Barbie Magic Funhouse can't be installed because it conflicts with sendmail and will break dependencies for Evolution is complete, utter and total, unadulterated failure.

It seems that you are referring to a Windows based install here, or at least that's the premise I'm working from. It's quite likely that this Barbie program is going to require DirectX of some version level, as well as other possible shared libraries from Windows. What does the software OEM do in this case? They include on the CD any of the possible shared library versions that may not be up to date, then the installer looks to see if it needs to upgrade the system or not.

Certainly the weakest point of RPM's is that they are simply awful at dealing with library dependancies. That doesn't mean that this problem can't be resolved, it just means there is a problem. The BSD folks recognized this problem a while back, and address it quite nicely with their package and ports system of installation.

Coming back to this example, in the FreeBSD world if a library equivalent to DirectX were to be needed by this Barbie program, the package would go and hunt down that dependency on the Internet. It's pretty powerful stuff, and goes a long ways to working around the problems that you've brought up.

To date, I only have experience with RPM's and FreeBSD's system of handling installations. I understand that Debian's package management has similar dependency finding capabilities. It's probably fair to say that none of the present solutions now being used are optimal. I would include even Windows installs as problematic in this regard, and anyone who has run into "Can't find VB400RUN.dll" before can certainly appreciate this.

I am of the belief that a truly optimal system can be developed, just based on what I've seen to date. Where I have hope here, I also have a great deal of doubt that the various groups backing their preferred method can step out of their foxholes long enough to work towards that.

Bottom line, there's more going on out here than just RPM's not finding dependancies. Have yourself a look about, there are some very cool things that are already in place, and in work.

Re:No one tackles the hard problems

ask why a new version of a package was released?
see a list of changes between old and new versions?

Well, RPM does include a Changelog which should include why the package was released, and what changes were made. check the --changelog option.

tell the system to apply only security or high-priority fixes?

You can do this mostly by installing a distro, and then tracking a particular version of it. Redhat-6.2 has lots of updates, but all of them fall into your 'security/high-priority' category.

tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?

It's trivial to setup something like this where you mirror the appropriate dir on updates.redhat.com, then have a script which does an rpm -F foo.rpm on every rpm whose name isn't listed in 'no-auto-upgrade.txt'. However, given your original statement, it's not possible. You're saying that you want it to automatically everything, except it should psychically know what you want to pick and choose from. Ummm... no matter how you cut it, you'll at some point have to tell the system 'upgrade or no'.

tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?

This is the default behavior of RPM. You have to use --nodeps to override it.

ask for packages that will help me convert GIF files to PNG?

You want natural language capability search built into your package manager? You've watched too much star trek. If however you did a quick search for RPMs that contained both 'GIF' and 'PNG' in their name on a site like rpmfind.net [rpmfind.net] you'd find gif2png [rpmfind.net] is readily available.

ask for only packages targeted at beginners?

I have no idea what use this is. Beginner is a very broad term. Is Enlightenment aimed at beginners? How about Windowmaker? The answer for both is a resounding maybe!, depending on the configuration. How about gcc, is that for beginners? After all, most computer barely-literates don't know how to use a compiler. And bind, that's definitely an advanced package right? unless of course you install a caching-nameserver rpm that helps the beginner have their own caching nameserver, then it's beginner. Or an obvious beginner package like grip, whcih isn't beginner at all, i mean, you have to know about mp3 encoders and cd rippers.

ask for only well-integrated, well-tested packages?

Use RedHat, they'll only give you these. If you stick to basics, unless you use Mandrake, you usually won't get anything that's not well-tested and integrated.

get reviews of a package?

Ah yes, all programs expand until they read mail. Or in your case, you're asking for the package manager to read newsgroups and mailing lists, so it'd be a newsreader too. Maybe we should just integrate this package manager of yours into emacs.

find out how to get started using a package?

The RPM format allows for certain files to be flagged as documentation and generally installs them in the path /usr/doc/$rpm_name. and man files in /usr/man. you can get a list of what it installed by doing rpm -qi package_name.

begin browsing the documentation for a package before approving a full installation?

again, you're asking the package manager to do things that just don't make sense. Why not read up on the software, then install it? Or just install it, and if it's no use to you, do an 'rpm -e'.

have some help in configuration updates?

These are called man pages, and documentation files. You read them and they help you. Or hell, if reading real documentation is too much work for you, then see if there's a HOWTO that you can peruse somewhere on the net.

Personally I use FreeBSD which has it's own unique set of strengths and weaknesses, and if you don't think anybody out there is thinking about this stuff, you should read this document [freebsd.org] which is a summary of the state of these things in FreeBSD, and some ideas on how to progress.

----------------------------

Re:I dont' see what the big deal is...

I LOVE rpm! What could be easier than rpm -Uvh file.rpm?

apt-get install package.

Try downloading gnucash and install it. It will fail with a bunch of dependencies. Of course, it's close to impossible to find the where those programs/libraries are, and if you find them, you can't find the rpms for them.

In Debian, 'apt-get install' will retrieve the dependencies too.

Re:Packaging is just plain dumb

Even windows does not do static linking. Windows has all those dlls that come with the packages. I am sure that Mac is probably the same. Static linking has its place, but not for everything. dll save space. If you have all static programs on your machine all programs would get to be big giant monsters that were memory hogs as well. You would not be able to dynamically load and unload dll's either. Sure you may have a faster program, but that extra speed would not be all that much to a shared object and ususally is not needed.

This is really off topic.

Now about rpm and apt-get which is what this was really about. RPM does allow you to save configs, that is whay I usually have all these .rpmsave files after I upgrade a program. I think it would be nice if there was a switch that could be passed to rpm like 'rpm -Uvh --keepconfig .rpm` to save my current configuration file without creating the rpmsave files.

rpm is not perfect. debs are not either. Last time I tried to install debain it did all its package checking at the time I selected the package rather than let me select the packages and then when I was ready to install tell me what dependancies I missed. I like rpm cause I think it was easier to learn than deb's, just my opinion though which where i am I am entitled to!

Now apt-get may work with rpms. This is good. So when does that project get started?

A second feature that would be real nice in rpm is more than just an rpm problems. It is a *nix make problem. Makefiles are not all the same. Some packages use automake and autoconf to generate the Makefile while some people just use make. Then there is really no way to know what it being installed if you are not the packager and without looking at all the sources. If I download a tar.gz and want to have an rpm out of it making that specfiles can be a real pain in the but, and half the time you can never be sure that you got all the files correctly. There has got to be a better way! If a program is in perl it may not use configure scripts it may just use a perl script. Maybe what needs to happen is a concerted effort into creatinga new system management tool. One that takes a snapshot of the system before a package is going to be insatlled and then one that takes one after. Window is doing something like this and allowing users to go back to a given point in time. So you could take a snapshot of the system before you install a program and then after you install it you can see what is changed. If rpm had this capability rpm would see what files had changed after you installed some programs ie after you do a make install or whatever. Those changes could be updated in the rpm database. If something failed the rpm database could roll the system back to before the fiels were installed. It needs some way of doing this. Maybe a program that could be turned and off at will. You could turn on the system file watcher and after you do a make install it would give you alist of fiels that have changed. It would have to be smart enough to ignore /proc of course and /tmp (or configurable to ignore certain directories) hmm ....

I don't want a lot, I just want it all!
Flame away, I have a hose!

apt vs rpm

I used RedHat for about 4 years, and recently switched to Debian mostly because of dpkg.

I'm sorry, but dpkg as a package management tool is so superior to rpm, that it was like going from Windows to Linux again. Yes, Windows is nice if you've never experienced anything else, but once you tried something better, you really don't understand how you could have been so blind.

Redhat 5.x used rpm 2.x. Redhat 6.x uses rpm 3.x. Redhat 7 will be using rpm 4.0. Guess what, each major version of rpm is incompatible with the previous version. This coupled with the fact that I have never successfully upgraded a RedHat system (I usually either reinstall or do a manual update, as in go through my list of rpms and do a rpm -Uvh package.rpm from the CD, making sure I don't upgrade packages that are newer than those on the CD).

In Debian, I changed my sources.list and did a 'apt-get dist-upgrade'.

apt-get install will ask stop and ask for configuration issues. I have yet to find a rpm package that did that.

rpm -bb -clean --rmsource package.spec is supposed to compile, create rpm, and remove the source and spec file according to the docs. It never removed the spec file in rpm v3.x

lets say I wanted to remove xanim. I have aktion installed dependent on xanim.

In dpkg, I would do:
apt-get remove xanim
Since aktion depends on xanim, dpkg will ask if I want to remove xanim to and *do* it in the same step.

rpm -e xanim
Failes because aktion (if the dependency is even set up) has something dependent on it. You then have to do a rpm -e for each dependent.

Quite frankly, having used both, I just like dpkg much better, I wish all Linux distributions would just bite the bullet and standardize on it. Heck, if each major version of rpm is uncompatible with the previous version, it's no harder to go over to dpkg than to go to the new rpm (just write a tool that convert the rpm database to dpkg's text based database).

Re:I wish I could do this myself, but...

As far as operability on a completely mucked system, I have on occasion relied on the (nice) fact that a .deb is really just an 'ar' archive.

Say I wanted to forcefully reinstall a package, not caring about the database and such, just get me my program back:

# mkdir /tmp/package-extract
# cd /tmp/package-extract
# ar x /path/to/archive/like/var/cache/apt/archives/file. deb
# cd /
# tar zxvf /tmp/package-extract/data.tar.gz

control.tar.gz in the same archive contains all the scripts and such, so you can even run those manually if you need to. And the package database is (for better or for worse) ASCII anyways, so even if you only can get 'ed' working, you can mess around with it anyway.

I used Red Hat and rpm for about 6 months. Then I discovered Debian, and liked it a lot better, largely because of its package management. rpm can conceivably do a lot of the things Debian packages can do, but Debian has it here, now. As for the multiple versions of packages advantage claimed by RPM users, I should note that Debian packages (most often libraries) can have a version appended to the end of the name, and many do. libc5 and libc6 are quite plainly two distinct packages as far as the package management system is concerned, even though they provide much the same functionality. This applies similarly with other packages whose maintainer(s) have judged that having two or more versions of that specific package on a system is useful.

As for the file dependencies, I can see how that is a good idea (you execute, link to, copy, move, etc. files, not packages), but as the article mentions, it expands the dependency tree quite a bit, and I have personally had no trouble with Debian's package-oriented package management (if you depend on one file in a package, you likely depend on, or could somehow benefit from, the rest of those files, and they would get installed anyway when you installed the package). Need the GNOME headers? apt-get install libgnome-dev. Not brain surgery, and beats Windows's install-remove system by a landslide. Mac uninstallers can leave things behind also, but being able to just throw away the app's folder, preferences, and in some cases control panel and extension, is a very nice idea IMHO, but it doesn't scale well. I'd like to see what OS X does. (pssst, anybody got the CD? Can you post an ISO?)

Re:One thing I hate about RPM

Hello...

rpm --relocate /usr/local/games/quake2=/quake2 quake.rpm

The Fundamental Mistake here

These guys are making a fundamental mistake. What they want is to make .rpm act like .deb. This is not going to happen in any meaningful way. .RPM and .deb are the result of fundamentally different design philosophies.

Yes, it is possible to make apt work with .rpms - but this will ONLY work satisfactorily with .rpms that are written with this in mind. The reasons given for using .rpm instead of .deb here basically boil down to there being more .rpms and more people using .rpm - but since all new .rpms will have to be produced to work with this system anyway, this is a false advantage. The installed base, the already existing library of .rpms, are going to be useless to this project in any case.

Obviously what they should do is just use .deb. The pre-existing base for .deb may be smaller than for .rpm, but it's infinitely larger than the pre-existing base of .rpms that contain the information needed to make this work, because that set doesn't exist at all.

ehhh.. maybe. but the author was in part wrong.

RPM's got its flaws--in particular the bloat of its cross-dependency database once a system's gone through a few big waves up upgrades. But Mr. Matsuoka--and Mr. Covey--show themselves to be surprisingly ignorant of RPM's capabilities.

What set off little bells in my head was his contention that RPM can only update files and doesn't run pre- and post-install scripts and can't prompt users for parameters and install options for the packages in question.

This is just plain wrong. An RPM can contain and run both pre- and post- scripts both during install and uninstall operations. Plenty of RPM packages containing shared libraries, for example, silently run an ldconfig after installation. RPMs of things like mysql and postgres often do a lot more--initializing a database, setting up default db users and, yes, prompting for things. If his SMTP MTA packages don't prompt for anything, that's the packager's fault. Hopefully Mr. Matsuoka's job at Connectiva isn't as lead packager for their distro.

It would be nice to see both apt and RPM adopt a rich XML-based standard for expressing prompts, defaults and so forth for interactive installers, along with a way to express what prompts can be silenced and with what effect, so that text, widget-independent GUI, and web-based (among others) interfaces to interactive installation can be built without breaking anything. But this wasn't Mr. Matsuoka's complaint. He seems to think RPM's can't be made to prompt users or execute scripts.

As for Mr. Matsuoka's other contention, that RPM needs changes in order to allow smooth auto-updating of packages, this too shows inexperience. I'm sure users of, say, Helix-Update, RedHat's Priority Update tool, and for that matter the fully-automated silent autoRPM utility would be surprised to hear RPM lacks such functionality. That he doesn't know this is kind-of-sort-of excusable, since it's not covered in the books and documentation for RPM. Not so the pre/post install script stuff. That's in the docs.

in defense of RPM

i'd like to make a little note in the defense of RPM's. I like 'em. I don't use 'em much, maybe thats why i find RPM so appealing.

When you're installing an application for linux, i am of the opinion that it's best to do it from source. The idea of pre-compiled binaries just doesn't sit well with me for quite a number of reasons. Foremost, i don't like the idea that i'm using a binary build on someone else's box. And i certainly don't like the fact that i don't have the source sitting in front of me to hack, if i'm bored, or to just peer into, etc. (pls no posts on src.rpm)

RPM's, i feel, are great for the little utils. Miscellaneous files that i need for x without wanting to download and compile those binaries on my own. I just download an RPM and whabam! it's installed. Dependency problems? --nodeps. Won't install for some other reason? --force.

Maybe there are issues to be addressed if you want RPM to become your standard installer for absolutely everything. Yes, Forest Gump needs something more powerful. My question is simply why argue about RPM or apt when you've got source?

It's like arguing whether you'd like to buy a pinto or a ugo when you can get a porsche for free. (some assembly required ;-)


FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network

Business Logic

I have used RPM (Redhat for 3 years & Mandrake for a while) and now use Debian (for one year now). I guess my question is this: Would not it scare the RPM based distros to go with DEB, when it would be easier to only install a distribution 1 time. I mean their has to be something to the fact that each time I walk into Best Buy or Comp-usa, I notice a new point release of Redhat, Mandrake, Caldera, or Suse...I think apt-get update;apt-get dist-upgrade would just rain on that parade.

What do you think?

No one tackles the hard problems

All of the package management systems duck the hard problems of creating a user-centered system management tool. Why can't I

• ask why a new version of a package was released?
• see a list of changes between old and new versions?
• tell the system to apply only security or high-priority fixes?
• tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?
• tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?
• ask for packages that will help me convert GIF files to PNG?
• ask for only packages targeted at beginners?
• ask for only well-integrated, well-tested packages?
• get reviews of a package?
• find out how to get started using a package?
• begin browsing the documentation for a package before approving a full installation?
• have some help in configuration updates?

This is an abbreviated list, but I've wished for some variant of each many times.

Note I acknowledge that these are hard problems. I don't expect them to get implemented overnight. The problem is, I don't see anyone even trying. (Possibly Helix Code, it's too soon to be sure; at any rate, they will need the help of the distribution maintainers to go all the way.) Someone could make a great contribution by seriously studying what users need to take control of their systems and designing a solution, not just looking for the next hack.

I use Debian personally. I think dpkg+apt has more cool hacks than rpm+autorpm (or whatever), but I don't think it's significantly further in the big picture. I do think it has more possibilities, given its philosophy and development community.

Finally, I know some moron will jump up saying that rpm wasn't meant to do all this, and its developers intentionally limit its scope. I don't care whether rpm solves the problem, or a system build around rpm solves it; I do care that the problem isn't being addressed.

I wish I could do this myself, but...

I wish I had more time to learn how to program, and then actually program something. Many of you will be familiar with GNU Stow [gnu.org], and maybe even some of you had tried it. Well, I have. It's pretty nasty. While it works, it is cumbersome. But, I strongly think they've got the right idea.

For those of you not familiar with GNU Stow, it allows you to install a program in an arbitrary subdirectory(say, /usr/local/stow/Quake2-version), and then it makes symbolic links, recursively, from the installation directory to the system directories. ie: /usr/local/stow/Quake2-version/bin/quake2 is linked to /usr/bin/quake2.

I really think that's an incredibly good thing. For many reasons, and let me elaborate.

If you're at an unfamiliar system, or you're using a rescue disk, you might not know of, or have access to a package manager. You can't add nor delete packages, and you can't query packages. You don't know what files a package contains, and you don't know to which package a file belongs. I feel it's imperative that you can accomplish all of those tasks with standard *NIX utilities(ie: ls, mv, cp, ln, rm, cat, etc., etc.). To see what files are contained in the aforementioned Quake II package, I'd just need to do a 'ls -R /usr/local/stow/Quake2-version'. To see what what package owned /usr/bin/quake2, I'd just need to do 'ls -l /usr/bin/quake2'.

Of course, a good symbolic-link-based package manager should be a bit more complete. Now, RPM(I don't know about APT) uses a database to store its information. I gotta say, that's pretty stupid(no offense, RPM guys - I'm sure you have good reasons). At least, it's not very robust, from a system recovery/stability standpoint. So we want to get rid of a database. After all, we want to be able to manage packages with standard *NIX utilities, if we're really stuck in a bind. So, I guess each package would have some files, in its installation root(ie: /usr/local/stow/Quake2-version/), describing some things. Files named things like Requirements, Provisions, PackageInfo, PackageConfig.

Requirements - Would have sections on both file-dependancies(ie: /bin/ls) if the package required individual files, and package-dependancies(ie: fileutils-4.0).
Provisions - Would have sections on libraries and possibly a seciton on packages which the installed package replaces(ie: Postfix replaces sendmail).
PackageInfo - Would have a description of the package, and some notes on how the particular package may differ from the standard source distribution. Also some user-friendliness things like the type of software(ie: System -> Libraries) and such.
PackageConfig - This would contain the pre- and post-install scripts(yes, we really want to know what a package does!), and maybe anything that was done during installation based on any input the user gave.

These are just ideas, and I don't have the skills or time to implement them, so don't take it to heart too much ;) To be honest, I don't think any new package management system will succeed unless it has compatibility layers for RPM and APT. Both on the shared-library leve, and on the command-line level.

'Round the firewall,
Out the modem,
Through the router,
Down the wire,

New things under development

The Linux Router Project is working on a radically different OS as well well as a new packaging system based on neither RPM or DEB.

For the last 3 years I've done nothing but heavy development work and sysadmin. (For self and on contract) I've worked with Solaris, Redhat, and especially Debian, and can honestly say when it comes to 'real world' production systems all of them suck for long term system maintainance.

Out of all of them Debian is still best all around. (System and packaging) But it's packaging system could be a hell of a lot better. (I'm not still running 'slink' on my box because I want to...)

I think when we are done with our new breed OS, all the linux 'vendors' are going to be brought to task to look at how we did our packaging. Probably some of them will be adopting it. (That's is if we don't over take them all first. : >)

This is a feature list of what we are working on:

[name withheld]
==============
Defined:
A Unix type system software managment format, utilizing
a logical hiearchy for root layout, with de-centralized physical data
distribution.

Features:
No centralized package or physical data location

Allows conflicting packages/applications to be installed at the same time.
Package managment tool is able to enable or disable installed packages
dynamically, while preserving package configuration autonomy.

Generic and distributed nature. Multiple hosts can share the same
package installation via network mounts, while preserving package
configuration autonomy.

Allows hand fitting of root components (outside of /usr/local) with no
package conflicts

Logical root extensions for chroot, remote host, or virtual machine operation

'Open' physical packaging format allowing easy creation, extension, and future enhancment.

it's not the format, it's the policies

The RPM format may have limitations. What's being compared is RPM-based distributions and Debian GNU/Linux. The Debian system is in a different category, simply because it's SO MUCH BIGGER. All the packages, even for really obscure things, are managed by the same organisation and forced to conform to a set of rules, rather than there being a core and a contrib section.

Don't look at the technology (RPM vs deb). Look at what the people are doing. What's going on in Debian's case is that they're doing a lot less (shoehorning each bit of software into their rule system) with a whole lot more. The sorts of things one finds in /usr/local (that is, not distributed with the OS) on a Unix you may well expect in /usr on a Linux system, since Linux distros ship them. The sorts of things which may live in /usr/local on a non-Debian system probably live (if they're DFSG-free) in /usr on Debian, simply cause it's broader.

This is another reason Debian's so anal about its Free Software guidelines ... if it doesn't meet the litmus test, then you can't distribute some version of it with all the paths changed to match the Debian universe, essential for integration and stability.

Re:ehhh.. maybe. but the author was in part wrong.

The author of the article must not have made an RPM before. Every specfile generator out there has a section for pre and post install scripts. Plus, there is no reason why you can't include other commands in the middle of other sections, as is appropriate on a package-by-package basis. As you mentioned, a /lot/ of programs run ldconfig.

Configuration programs can be run also. Take the SSH RPMs for example. After installing the server RPM, it generated public and private keys. Saved me the trouble of doing it by hand, and made sure it was done right. I believe the client RPM even asked for a keyphrase. There's no explaination for what the author of the article said about not having configuration tools, except for inexperience.

I do agree that standard configuration parameters would be a nice addition, but there is absolutely no reason why package maintainers should have to conform to anything other than the stand specfile pre- and post- install sections. It allows them much more freedom and ease of use to use the scripts that come with their tar files. Why bother converting them to yet another format?

----

linux-ports?

The small amount of time that I have been with FreeBSD, I am amazed at the power and flexibility of the ports system.Sure there's a few rough spots, but those are easy enough to polish out.

For those that don't know, where the synopsis: the ports system is a collectin of makefiles and diffs to properly fetch, extract, configure, build, install and register a software package for the target system. A FreeBSD package is simply a port that has been precompiled, so you don't have to be afraid of typing "make" at the commandline. And these packages have utility programs along with them, like pkg_add, pkg_remove, pkg_info, etc. Dependencies are kept track of, including checking for individual libraries instead of monolithic packages. Very similar to Debian's method.

So how does this fit into the Linux continuum? Well, right now there is a concerted effort to make a unified BSD ports system, instead of separate ones for each *BSD. There is no reason that Linux could not get involved so that there will be a linux-ports variant. Hell, there's no reason that it couldn't be a grand unified UNIX-PORTS! And there's no reason that deb and rpm packages can't be fit into the system as well. I keep hearing rumours that Slackware will go to a ports-style system, and I hope they do.

If you're a potato or hamm head, and have always criticized the ports because it didn't have some minor feature, now is the time to get involved.