[H-GEN] SMALL RPM PROBLEM

[Greg Black]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

I'm sorry for continuing this topic as I suspect that its value
is declining as we go on, but there is one point in Jason's
message that I think deserves some comment.  I'm not going to
discuss all the other items in the various other messages that I
don't agree with although I'll be happy to discuss this a bit
more at a meeting.  Perhaps we could run a panel on this subject
if people are interested?

Jason Parker-Burlingham wrote:

| Well that's just silly.  A package manager shouldn't let you do that
| (just as dpkg doesn't; foo-1.3 is an upgrade and will replace
| foo-1.2).

Here we hit a real stumbling block for any package manager.  I
have no idea how best to solve it, but I already know I don't
like the "solutions" I have seen.

Just because I am installing foo-1.3, that doesn't mean I no
longer want foo-1.2 and it certainly doesn't mean I want foo-1.3
to suddenly prevent me from having continued access to foo-1.2.
Any package manager that tries to enforce such rules is broken.

I might have python-1.5.2 installed and I might be happy with
it.  Then I hear about a python-based tool called pyfoo.  I go
to install pyfoo-0.1 and find that the package builder decided
to make it require python-2.1.1 and so suddenly python-2.1.1
gets installed for free.  If a large part of my software (not
under the control of the package manager) really does depend on
python-1.5.2 and will break under python-2.1.1, then I have a
real problem[1] (apart from the question of whether I want two
complete python installations).

In fact, python installs those two versions in different places,
but the python binary will be the one that was installed second;
of course, the desired one can be accessed as python1.5 or as 
python2.1, but not without changing scripts (and making them
break if we upgrade python again).

As of today, I have 779 packages installed on my home network,
including many versions of Tcl/Tk (as I use lots of Tcl/Tk
applications and each one seems to want a different version of
Tcl/Tk).  I also have conflicting versions of several libraries
used by various packages.

In some cases, I build by hand from source because I'm a tester
for the software (e.g., bash); in some cases, I do it because
the software is inherently broken (e.g., PostgreSQL, which I
love but which constantly brings out new versions that cannot
interact with old databases[2]); and in some cases, I do it
because the dance of dependencies is just too tricky for the
packages to get right for my requirements (e.g., apache or TeX).

I'm not against package systems and I do use them extensively.
I don't think they're perfect and I think they do some things
really badly.  What's true for me won't be true for everybody,
but nobody can seriously claim that any current package system
does everything right -- and I doubt if such a system can even
be specified, let alone built.

[1] The Python people did make some incompatible changes in the
    syntax accepted by the parser and that really did break a
    large number of Python programs that my customers depended
    upon when their Python installation was upgraded.

[2] For PostgreSQL, you have to have old and new versions
    installed somewhere; you then use the old version to dump
    your data (while you lock the users out), then you load the
    data into the new version, then you shut down the old server
    and start the new server and tell the users to re-start
    their applications so they can connect to the new server.
    Obviously, somewhere in the middle of this (after building
    the new version) you have to create a dummy database and use
    it to test all the software that will interact with it via
    the new server.

Greg

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/