[pacman-dev] [PATCH] add support for .so dependencies

Thomas Bächler thomas at archlinux.org
Tue Aug 18 07:30:16 EDT 2009

Allan McRae schrieb:
> Case #2 occurred with pacman and was corrected by correcting the 
> versioned dep.  Also, it would not have occurred if -Wl,--as-needed was 
> used.  Automatic .so deps would have stopped it but so would have 
> correctly versioned deps.  So in that situation we already have the 
> tools to deal with this.

This is a rare corner case. Let's ignore it for now.

> Case #1 is a case whether this could be useful.  But has anyone thought 
> about why this is happening more that it used to?  Surely there were 
> lots of people who did a "pacman -Sy pkg" in the past.  The answer... 
> excess versioned deps.  If we had no versioned deps, only that package 
> specifically being updated would be affected.  In general people would 
> not tend to do a "-Sy pkg" with a library and thus the lack of versioned 
> deps only ever caused a minor inconvenience to the user who did the 
> wrong thing.
> Adding sodeps would just make it difficult for people to do a "pacman 
> -Sy pkg" and those people would end up doing a "-Sd pkg", which would 
> have the same result as no versioned deps.

It would simply fail or request to update tons of other packages. The 
problem here is, it fails silently. pacman does not realize that by 
upgrading dependency A for package B, it makes A incompatible with many 
other packages. There is no warning and there is no way a user can avoid 
such situations, other than -Syu'ing.

Personally, I recommend to always do a full -Syu before messing with 
your system at all, but I realize that is not always possible.

> I think a better approach is to have a very few system critical packages 
> providing/depending on the relevant libs and stop over using versioned 
> deps.

If we use fewer versioned deps, we solve a new problem by reverting to 
an old problem.

First of all, I think that adding soname-provides to every package 
automtically won't hurt anyone (increases package built time slightly) 
and won't break anything. Even if we never use it, it's nice to have 
them in pacman -Qi.

About versioned dependencies: I am unsure when we should do this: For 
system-critical packages, definitely, this will simply prevent pacman 
from breaking those, which is a good thing. For everything else - 
there's pros and cons, I don't want to complicate our package management 
too much. One idea is to have a sodepends=(libreadline.so) statement, 
which would only add a versioned depend on the right libreadline soname, 
but not on other libraries. Another idea is to implicitly add soname 
dependencies, but only for libraries owned by packages that are 
explicitly specified in the depends array (maybe print a warning for the 

I want to explicitly ask you about the cons for this feature. What do 
you think is a hard reason NOT to do it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.archlinux.org/pipermail/pacman-dev/attachments/20090818/0d087417/attachment.pgp>

More information about the pacman-dev mailing list