On 22/01/11 00:57, Florian Pritz wrote:
On 21.01.2011 15:49, Dan McGee wrote:
On Fri, Jan 21, 2011 at 8:25 AM, Florian Pritz <bluewind@server-speed.net> wrote:
On 19.01.2011 19:54, Dan McGee wrote:
It is most definitely not a valid pkgver (dash) or pkgrel (not a number).
The dash here just seperates pkgver from pkgrel.
Did a quick test with libc.so=6-x86_64_Linux as dependency and a package called libc.so with that pkgver and pkgrel and it worked just fine.
Perhaps more importantly, this is still wrong (I can't run your i686 binary on my i386 system as it seems to indicate)
http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010410.html
That reply is just wrong... i686 is not a restricted flavour of i386. It is the other way around. I can not run i686 optimised software on an i386 system. Just ask all the Via C3 owners who do not have that "nopl" instruction and the joys they had with glibc-2.12. So there is a real problem that you can not get the correct value out of the library on i686 systems. We could use CARCH, but that does not work for multilib stuff, which was the entire point of including it in the first place... This needs left out unless the correct value can be given.
and if we do keep it, it has *nothing* to do with a version in the normal ordering sense- it would belong as part of the provision name.
I had that before and Allan didn't like it.
http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010420.html
I did not like provides=(libfoo.so) magically turning into "libfoo.so-i686" in the .PKGINFO file. The details of the package should reflect what is in the PKGBUILD. Allan