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

[Nezmer]

>> 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).