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

[Dan McGee]

Wow, this degenerated into a flamewar quickly. Can we all calm down
just a tad? If we were truly at an impasse, Allan and I wouldn't even
be looking at these patches. The biggest reason I'm putting up a stop
sign and red flags is the lack of explanation at the questions I've
posed, and stating I've only offered destructive criticism is not the
truth- I just don't understand this whole thing.

On Fri, Jan 21, 2011 at 10:54 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> 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.

Taking a step back here, if we want to not lock ourself into ELF-only
(OSX does not use it), it sounds like using objdump due to it's use of
the BFD backend which understands multiple file formats. From objdump
-a, although the output is rather arcane, we should always be able to
get the file format of the library, which I believe is the most
important to matching what the linker does.

Sidenote: I saw this when running objdump --info on my x86_64 box:
plugin
 (header little endian, data little endian)
BFD: BFD (GNU Binutils) 2.21.0.20101217 assertion fail
/build/src/binutils/bfd/plugin.c:453
objdump: plugin: Bad value


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

See, this is what I still don't understand. Is this libprovides, or is
this "well we'll hijack your provides array sometimes depending on
what you put there".

It *still* hasn't been explained how this thing works in either a
commit message or docs. Do I include soprovides=() in my PKGBUILD? Do
I need to insert something in provides=() to get a library to show up
in the final package? Is it all completely automatic- all libraries in
the package get an automatic provide entry generated? This is why I am
so damn frustrated with these patches.

>
> So, to summarize:
>
> 1) Dan does not want a new PKGINFO field to be introduced for this.
Where did I say that- if I did, I'm not remembering.

> 2) Allan does not want any auto-generated meta-info in the provides and
> depends in PKGINFO.
No, he stated he doesn't want *magic changes* to data the user
specified in the PKGBUILD. I think he and I would be more comfortable
if this was less magic.

> 3) Dan does not want non-versioning information in the version field in
> provides/depends in PKGINFO.
Sure.

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