[pacman-dev] Inconsistency in detecting ARCH Was: implement .so dependencies?

Nezmer arch at nezmer.info
Wed Feb 10 12:01:56 EST 2010

>> I disagree in the "arch" part. It might not be as important now, but in
>> the future it could cause problems if we end up havnig multiple
>> architecture libraries in one system (and ultimately I want to make that
>> possible, if I ever get to it). If we could agree on this scheme:
>> soprovides=(libreadline.so)
>> would generate
>> provides=("${provides[@]}" libreadline.so-x86_64=6)
>> Then the "weak -d" flag could ignore the =6 version above and we still
>> have everything we would need for matching so-names.
> OK.  I will concede the need for the arch part then.  But it needs some 
> changing.  As I said before, I would prefer soprovides detected by ending 
> in ".so" in the provides array and I do not really like entries in the 
> provides array automatically changing apart from versioning.  So...
> provides=(foobar libfoo.so)
> would result in
> provides = foobar
> provides = libfoo.so=6-x86_64   (does that order look right...?)
> in the .PKGINFO file.
> I am fairly sure that pacman can handle two packages providing different 
> versions of libfoo.so but that needs checked.
> A patch that did this would be very acceptable to me.
> Allan
What arch are we talking about here.

I ran into this inconsistency when I used pacman/makepkg in FreeBSD.
makepkg uses CARCH , pacman.conf uses "uname -m" which returns amd64 not
x86_64 on FreeBSD , and If I'm looking at the right patch "readelf -h"
is used here which will return ELF32 in 32bin-* and 32lib-* packages and
that is technically correct and an intended behaviour (I think).

More information about the pacman-dev mailing list