[pacman-dev] implement .so dependencies?

Allan McRae allan at archlinux.org
Thu Feb 4 09:32:56 EST 2010

On 04/02/10 22:54, Thomas Bächler wrote:
> However, it's worthless to discuss implementation and concepts if the
> idea is entirely rejected by our main makepkg developer.

It is not entirely rejected.  I just have very limited time at the 
moment so end up just pointing out what I do not like about ideas.  I 
actually do like some of the idea, but there are parts I obviously 
dislike.  In future I'll put some effort into being clearer about that...

Anyway, here are some of my opinions on this idea:

1) I'd prefer just using a single depends array rather than an 
additional sodepends array.  A version of pacman's "-d" ignoring 
dependency versioning would not require a separate array and would be 
far more useful than one that ignored sodepends.  I think that should be 
implemented in pacman no matter what.

2) I do not like "magically" adding libraries to the depends/provides 
array.  I really want them to be manually specified (versions can be 
automatic - see #3).  For example, the readline package would want to 
provide libreadline.so as that is important but libhistory.so is really 
not...  What is important or not would be up to the distro packagers.

3) I would like the sodeps to be listed like (e.g) "libreadline.so". 
This makes the dependency named closer to what is actually is.  Makepkg 
could recognize the ".so" at the end and use readelf on the binaries and 
automatically add the relevant version.  The "soname-arch" type prefix 
is ugly.  "soname" is covered by the ".so" and multi-lib stuff is not 
really as critical so "arch" is not really needed either.

These three points would go a long way to alleviate my concerns about this.

 From my suggestions it should be clear that I really do not want every 
package to have all possible so-provides and -depends added 
automatically.  That seems too much like an even poorer implementation 
of rpm to me and would be very, very difficult to get around all the 
edge cases.


More information about the pacman-dev mailing list