Re: Discuss-gnustep Digest, Vol 2, Issue 12

[Jonathan Gapen]

On Sat, 4 Jan 2003 discuss-gnustep-request@gnu.org wrote:
> From: Tim Harrison <tim@linuxstep.org>
> ...
> I don't see too many types of package management systems.  The way I see
> it, the primary three are RPM, DEB, and TGZ.  Beyond that, there're
> things like Portage.
>
> The thing is, package management does not stop at package format.  It
> goes into how to add, remove, and maintain that package once it is on
> your system.  THAT is where the problems lie.  Anyone who's been stuck
> in RPM dependency hell is all too familiar with this.
> ...

     Yes, the two biggest issues I have with package management are
database management and dependencies.  The trouble with the package
database is that it's extrinsic to the installed package files, thus
there's the possibility of the package manager's idea of what's installed
getting out of sync with what's really installed.  Occasionally, I use
find and pkg_which on my FreeBSD system to identify files that don't
belong to a package and then delete them.  There are a lot of 'em that get
left behind.  Once in a while, this deletes a file needed by an installed
package, but that that package didn't claim.
     In my ideal operating system, the filesystem is a database (or has
database features), so the package manager could simply query the
filesystem to get a list of installed package files, and it would be
automatically kept up-to-date if files moved or changed names.  Maybe
ReiserFS will make this possible?
     That might also help a little bit with the dependency problem, but as
I see it, the Unix shared library implementation is terrible.  It's
fragile, has poor backwards compatibility, is inflexible, is slow, and
every platform has a subtly different implementation!  If your executable
links to libxml2.so.4, it needs THAT file, and libxml2.so.5 won't work.
You don't know whether libxml2.so.5 is compatible, anyway.  Loading your
executable fails if libxml2.so.4 isn't available-- you as the programmer
have no choice about whether to run without it.  And all those name
lookups when linking many shared libraries make process startup slow.
     A shared library system that addressed these deficiencies would
eliminate "RPM dependency hell" for the most part.  A new package might
require a newer version of libxml2, but you could install that newer
version without the need to re-install every other package that depends on
libxml2.  Wouldn't that be nice?
     Furthermore, such a system would allow an easy, completely-functional
implementation of frameworks in GNUstep.  Well, we can dream...