[pacman-dev] implement .so dependencies?

[Thomas Bächler]

Am 03.02.2010 01:39, schrieb Allan McRae:
> I will have a decent look into that patch later, but I still think it is
> a bit of a false sense of security.
> 
> e.g readline-6.0 and readline-6.1 both provide libreadline.so.6.
> However, building bash against readline-6.1 and running against
> readline-6.0 results in a non-booting system...  (Trust me, I got the
> bug reports).  If this approach does not work for even one of the most
> critical pair of packages on a system, then I do not see what we are
> gaining.

I get the feeling that you are desperately looking for reason to not
implement a feature that is obviously a necesity. It also seems you
haven't understood what the purpose of this feature is.

The SO name guarantees that when you build a binary against readline
6.0, you can use it with any LATER version of readline (e.g. 6.1) until
the SO name changes. It does NOT guarantee that a binary built against
6.1 will work with 6.0, although the SO name is the same!
Dependencies based on SO names will prevent you from upgrading a library
to a version that is too new for the packages that depend on it. It does
not prevent you from upgrading a package while leaving the library at an
old version.

We currently use (upward, >=) versioned dependencies to ensure the
latter case is alright (systems won't break when you upgrade a package
that needs a newer library). However, we do not have a working mechanism
to prevent you from upgrading a library that is too new for a binary
depending on it. Manually introducing downward (<) versioned
dependencies for this is impossible, as you would have to know in
advance with which (future) version of an upstream library the SOname
will change (some packages keep this in sync with the major version
number, but most don't).
In this sense, SOname depends are not meant to replace versioned
dependencies, but to complement them.

> Finally, this would prevent proper upgrades to partially complete
> rebuilds.  That is fine for some users who would like such things, but
> the people doing and testing a rebuild would have issues.  I upgraded
> the libpng/libjpeg rebuild packages while there were still several
> packages needing to be rebuilt for my system.  With this patch, I would
> be required to do an incredibly stupid "pacman -Syud".

This is a solvable problem - a weaker -d flag could ignore any versioned
dependencies and only take the package names into account. And I guess
implementing such a flag wouldn't be too hard either.

The latter argument again makes me think you are desperately looking for
a reason why this would be a bad idea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/pacman-dev/attachments/20100203/84158204/attachment.bin>