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 <[email protected]> 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.
