[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.
Allan
More information about the pacman-dev
mailing list