Re: When packaging systems go awry (Was: Re: Are we losing users to Gentoo?)
On Thu, Nov 21, 2002 at 11:44:21AM +1300, Corrin Lakeland wrote:
[snip]
> > Ick. If I had to choose, I'd stay away from rpm for this one reason alone.
> > Experience shows that installing the same package more than once, esp.
> > with different versions, gets you into an absolute, total mess.
>
> > Once you get into this state, you start having to solve issues like not
> > removing a file until both packages that ship the same file are removed,
>
> No. Consider for example
>
> /opt/qt2/lib
> /opt/qt3/lib
> /opt/kde2/{bin,lib}
> /opt/kde3/{bin,lib}
>
> Of course, this wastes space, although that may be avoidable with hard links.
Sure, but what happens when you have point releases of KDE/QT? Make
/opt/kde2.1a/{bin,lib} and /opt/kde2.1b/{bin,lib}, etc.? (Unless, of
course, you enforce a rule that only packages with major version different
can be simultaneously installed. But that assumes that upstream doesn't
introduce ABI/API incompatibilities in point releases. Alas, this is very
risky in the real world. A version number is, after all, only an arbitrary
identifier attached to different versions of a piece of software.)
> A small amount of LD_LIBRARY_PATH magic _might_ be required, but certainly no
> keeping track of multiple files. I'm not saying this is the right way to go,
> just that you don't need to do super smart things to keep track of multiple
> versions of the same files.
LD_LIBRARY_PATH magic will work only for dynamic libs. (And even that gets
tricky--if program X can only work with KDE2 and program Y can only work
with KDE3, you need some way of keeping track of the LD_LIBRARY_PATH
wrappers, preferably automatic. It gets messy.)
What about development packages that contains, say, include files? What if
there is some important header file change between, eg., KDE1.2 and
KDE1.3, say in some compile-time constant? If other packages are used to
using #include <kde.h>, you have the problem of arranging for compile-time
path arrangements. (OK, the KDE example is totally hypothetical and is
probably untrue of the real KDE system. But you get the point.)
But it gets worse. Many development systems have runtime configuration
files. E.g., superserviced opens a UNIX-domain socket in
/var/superservice/pipe. All programs that use superserviced are used to
looking in this exact path for the socket. Unless you do shenanigans with
chroots, I don't see how two (potentially) incompatible versions of
superserviced can co-exist. This problem isn't just for pipes; stuff in
/etc, or loadable .o modules in /usr/share/lib, or many other things, have
the same problem. Of course, we can blame upstream for bad design (should
incorporate version numbers into files, should not hardcode file
locations, etc.). But in practice, there's no avoiding situations like
this.
Add to this mix programs of the *same* version, but compiled with
different options, co-existing on one box. It's a mess you really don't
want to touch. (E.g., trying to install multiple configs of the same Linux
kernel, and have /lib/modules totally screw up on you unless you have
taken the proper precautions.)
I might have stretched my illustrations some, but the point is, allowing
multiple versions of the same software to coexist is generally Very Bad
(tm). Unless, of course, the software has been designed to handle such
things. Properly-designed .so's are an example---but most people don't
have such architectures in mind when they design their software. And even
.so's have their faults--remember libc5 -> libc6?
Debian's enforcement of only one version per package is a Very Good Thing.
A lot of very nasty stuff are neatly avoided just by doing this. And
packages that *can* co-exist can be made to do so by incorporating the
version number into the package name, eg., libpng2, libpng3, etc.. But as
we all know, even these packages have been known to cause a lot of grief
if not handled with utmost care. (And yes, I deliberately picked libpng
as an example. :-P) We can blame upstream, we can blame bad design, etc.,
but it doesn't matter; the best, safest thing to do is to NOT allow such
coexisting packages by default. (Albeit providing a way to circumvent this
if the packages are designed to handle it.)
T
--
He who sacrifices functionality for ease of use, loses both and deserves
neither. -- Slashdotter
Reply to: