[Gllug] gtk+ or Qt? (or others?)

[Nix]

On Mon, 13 May 2002, tet at accucard.com stated:
> Which reminds me of a long standing problem I have with packaging
> systems. One of the huge benefits of Unix is that it's quite possible
> to have multiple versions of the same library installed concurrently,
> thus avoiding the DLL nightmare found on windows. Sounds great in
> theory, only current packaging systems prevent it!

Er, no, they don't.

> This leads people like RH, SuSE, etc. to resort to crude workarounds
> like renaming packages (RH ship both glib, and glib10, for example).

That's not a `crude workaround'. The package name is a close analogue to
the soname; the soname is the unit of library reference on Unix boxes,
so this is the correct approach.

What existing packaging systems *do* get a little bit confused by is
symbol-versioned libraries and all that they imply; but as long as you
only allow package upgrades, not downgrades, even this works.

> That in turn screws up dependencies for third party packages. Do they
> depend on glib, or glib10? If you put a dependency on glib now, then
> your package may fail on RH8.0 where it'll have been renamed glib12

The solution is packaging policy. *Always* name your library packages
something like `glib12'; never call it `glib'. Anything else is
short-termism because it assumes that the library soname will never
change.

(Also, never rename library packages.)

Debian gets this right.

--- of course, you could equally well call them glib version 1.2 and
glib version 2.0, but glib1.2 and glib2.0 are equivalent (if uglier).

> It's been a long time since I've used Debian, but I assume dpkg to
> have the same restrictions.

Yes, but they're not restrictions, which is why nobody cares about
fixing them much.


What *is* annoying is that the SONAME scheme provides no way to say that
`this library depends transitively upon bar.2 only; no other major
version of bar is permitted.'

This showed up most obviously in the libc5->6 transition and in
libstdc++ transitions, but also it's showed up for me personally in
libpng, libXm and libncurses transitions, and it'll show up *massively*
in the future if libgcc_s.so ever bumps its major version number (which
it won't if I have anything to do with it).  I can't see any way of
fixing this general problem without massively uglifying SONAMEs and
shared library names, either.

-- 
`There are not words enough to describe how fucked up imake is.'
                                        --- Peter da Silva

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug