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