Am 21.01.2011 18:35, schrieb Dan McGee:
Wow, this degenerated into a flamewar quickly.
I deleted all flames before submitting this post. That said, I was a bit pissed about that last part of Allan's post.
and stating I've only offered destructive criticism is not the truth- I just don't understand this whole thing.
That statement was directed only at the part of Allan's reply that I quoted right above the statement. It was not in any way meant for you, or to any other part of Allan's post.
On Fri, Jan 21, 2011 at 10:54 AM, Thomas Bächler <thomas@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.
I do not want to lock anything explicitly to ELF. Considering that OSX also supports 32 and 64 bit libraries on the same system (and ones that contain both), it's a bad idea. The question remains, how portable can we even be here? Do we maybe need support for different binary formats, implemented in different ways?
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.
The original idea was this: makepkg automatically adds provides for all libraries with a proper SONAME. These are added as provides to PKGINFO in addition to the user-specified provides. Alternatively, the PKGBUILD has to specify which libraries to add. So we would write soprovides=(libfoo.so) and this would turn into a provider for PKGINFO that would contain some information about architecture and SONAME. I don't like this option because the list of libraries is maintained by a human and not the computer. TBH, reading the current patch again, I am unsure what it actually does now. I think it is using the first option.
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.
Now that you ask, I am not 100% sure you even did. I thought I remembered something from a few months back. I apologize for not confirming this. But back to the point: Would you want this information separate? Adding a new field to PKGINFO here would essentially duplicate the whole provides/depends handling, and add new pacman code. When adding this auto-generated info to PKGINFO's provides and depends, there are no changes in pacman.
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.
And what is "magic"? It is simply automatic. Furthermore, as far as I can see, there are no changes to the user data, but only additions to it.
3) Dan does not want non-versioning information in the version field in provides/depends in PKGINFO. Sure.
So, let's summarize again what we want (because it seems you don't understand that): 1) We want to have information in the PKGINFO that tells the user and pacman which libraries are included in the package, and what their SONAME versions are. 2) We also want (optional?) information in the PKGINFO about which libraries in which versions are needed to run this package. 3) We want this information automatically generated, not manually maintained. The least invasive approach in our opinion was to add this information to PKGINFO's provides and depends, as it would work without any changes to pacman. This means that the provides and depends are extended by auto-generated ones. Nothing is magically modified or removed. Now, as everything we suggested is so weird to you: How would you want such a feature implemented?