.comment: Taking Inventory - page 3
So Much for Source Code
What we need, then, is some way of reconciling all of this irrespective of distributor, package manager, or our own personal computing habits, which might include the actual use of source code. A lasso that rounds up the disparate ways people have come up with of bringing in and keeping track of software. A super-package manager.
Is this possible? Well, it ought to be. We already have the locate database, which is usually updated via a cron job, typically in the middle of the night. It is fairly brain-dead, but it's supposed to be: All it does is take inventory of the files on the system. It does not care about dependencies. Its job is to make the "locate" command work without having to scan the entire system every time. (If you don't see the sense in this, sometime do an "updatedb" as root, and time it.)
And we already have "ldd," which tells us about library dependencies.
We further have the database kept by whatever package manager is used by the distribution. There are package managers for just about every way in which binaries are distributed. Each of these keeps a database that is a lot smarter than the locate database, because it catalogues the package whence a particular file came, keeps track of dependencies, and so on. The big problem is that it doesn't communicate with anything else.
If we cannot agree on a standard base distribution -- and history suggests we can't, even though the reasons mount for us to do so and some of us hope that criticality will be reached, such that a solid standard base is inescapable -- perhaps we can arrive at an all-encompassing package manager. I'm talking about one that keeps one and only one database, that intercepts all the calls made by any of the other package managers in much the same way that CUPS traps a variety of printing commands and converts them into something useful. Then, if you want to install a .tgz package from Slackware, or a .deb, or an .rpm from any distribution, it would handle it, resolve dependencies, and so on.
Actually, "so on" is quite a lot. The naming conventions, especially among libraries, are tough to reconcile. Determining whether the demands of one package are met by another, from a different package management system, would be troublesome.
What else would this super package manager of which I'm dreaming -- I heard you think, "in your dreams!" -- do? It would also trap "make install." This would keep the database informed of things compiled locally and even run "ldd" to establish dependencies. And as long as we're here, there are a couple of other nifty little tasks it could perform. One is provide a place for setting environment variables and enforcing them, so that an .rpm that wants to throw KDE or Gnome into /usr would think it's doing so, while the package manager puts it all wherever the user has decided it should go. Yes, I know about relocating .rpms. I also know that this doesn't always work and that it's sufficiently obscure that users often forget to employ it. Another is keeping track of orphaned files and symbolic links so that the fastidious user would be able to find easily and deal with the dead leaves on the tree.
In discussing this with various people who are deep into the mechanics of package management, I've been advised that arriving at such a system would either be fairly easy to implement or among the most maddeningly difficult projects ever contemplated. I don't know who's right. It would certainly involve a daemon, which always raises security concerns.
It's not something that could be undertaken lightly, and it's not something that is likely to find distributional sponsorship -- these guys can't agree on a standard base; there's no reason they'd agree to let their own little package management system get co-opted by a supersystem that wouldn't benefit anyone but users.