[pacman-dev] [PATCH 4/5] makepkg: add soprovides support

[Thomas Bächler]

Am 21.01.2011 17:01, schrieb Allan McRae:
> 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.

That is not the point. We should reflect what the dynamic linker tries
to do whenever we want to load a binary:

1) If we install a i686 version of libfoo.so.2 onto a i386 system, the
linker will still try to load that version (and fail with SIGILL).
2) If we install a x86_64 version and a i686 version of libfoo.so.2 into
the system, and launch a 32 bit binary, the linker will determine that
it cannot load the the x86_64 version, but the i686 version.

So, in order to "do it right", we only need to reflect the distinction
the linker does in 2). Not even the linker makes the distinction in 1),
so why should we?

And now think about use cases: The package architecture is already in
PKGINFO. So the only distinction we need to make is between 32 bit and
64 bit binaries - the only case where you are able to run more than one
architecture in the same system is when executing 32 bit binaries on a
64 bit platform with a backward compatibility mode for 32 bit. (AFAIK,
this is not only the case for x86, but for some other platforms, too).

The only info we should include into the soprovides/depends is whether
we have a 32 bit or a 64 bit binary. There shouldn't be an explicit
statement about architecture.

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

I think my previous comments should make this irrelevant, unless I am
completely wrong.

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

So, to summarize:

1) Dan does not want a new PKGINFO field to be introduced for this.
2) Allan does not want any auto-generated meta-info in the provides and
depends in PKGINFO.
3) Dan does not want non-versioning information in the version field in
provides/depends in PKGINFO.

Where does that leave us? Essentially, we cannot get this feature
implemented, as all those restrictions combined leave us with no
options. Clearly, you don't see any options either, as you only provide
destructive criticism, no suggestions on how you think it should be done.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/pacman-dev/attachments/20110121/f2840743/attachment-0001.asc>