Multi-arch ELF dependency generation (v6 packages) #3578
Conversation
Do away with the silly typedef while at it.
Rename addDep() to addSoDep() to hint at the intended use, and add a bare version of addDep() that has no extra logic. It's a thin layer of isolation but isolation nevertheless. No functional changes.
Allegedly no functional changes.
Don't bother checking for non-empty soname in the callers, addSoDep() will check for this anyhow.
The marker and ver don't *need* to be STL strings, but life is simpler if they all follow the same conventions. Just pass empty strings in place of NULL now and adjust the logic accordingly.
Traditional rpm dependencies have only supported biarch style installations between 64bit and "something else", traditionally of course 32bit. This has been denoted with (64bit) markers at the end of ELF dependency tokens for some 64bit architectures and for others not, and lets a dependency token of a completely different architecture satisfy that of another. This is inconsistent and limiting at best. Add a new multiarch mode for elfdeps where each ELF dependency token carries an ABI identifier consisting of the base architecture, it's bitness and endiananess, optionally followed by arch-specific flags. v4 packages continue to use the traditional biarch dependencies, for v6 packages we use the new multiarch style. It's possible to generate both for transition-period compatibility though. Inspired by and loosely based on an earlier patch by Neal Gompa. Fixes: rpm-software-management#2197
|
Could you describe a couple of examples of output so I can visualize this better? |
|
There are many sample outputs in the test-cases, but here's a few more :
|
|
So very similar to what I did for #1038, then. |
|
Yup - said as much in the commit too. |
|
The main "innovation" here is really the per-arch flags which allow the rest of the string to be easily generated from the ELF content directly, without needing special code logic and oddities like the x32 thing that made you weep in your version 😅 |
|
😆 |
|
Will this include some tooling to also solve the "requires" side? To help with cases such as https://src.fedoraproject.org/rpms/rubygem-ruby-vips/blob/137e3adee00c987c5c0b9f2d746ffb8b415f930b/f/rubygem-ruby-vips.spec#_24-25 |
| { ELFDATA2LSB, "l" }, | ||
| { ELFDATA2MSB, "b" }, |
There was a problem hiding this comment.
I think I still prefer le and be here.
| if ((ehdr->e_flags & EF_ARM_ABI_FLOAT_HARD) == EF_ARM_ABI_FLOAT_HARD) | ||
| flags += "h"; | ||
| if ((ehdr->e_flags & EF_ARM_ABI_FLOAT_SOFT) == EF_ARM_ABI_FLOAT_SOFT) | ||
| flags += "s"; |
There was a problem hiding this comment.
The point with the flags field is that they're all single-letter items so you can have the whole alphabet's worth of them. Humans are not the primary intended audience of these dependency values, it's enough that a human can easily compare two values to see if they differ. The meaning of these flags of course needs to be documented, I'll try to add a doc blurb today to make it easier to see what's what.
| static void x86flags(GElf_Ehdr *ehdr, std::string & flags) | ||
| { | ||
| if (ehdr->e_machine == EM_X86_64 && ehdr->e_ident[EI_CLASS] == ELFCLASS32) | ||
| flags += "x"; |
There was a problem hiding this comment.
So, is this means we get x86-64x? I'm not sure this makes any sense over using -x32 here and getting x86-64-x32 as the value.
There was a problem hiding this comment.
No no. You get "x86" from as the arch, "32" as the bits, "l" for endianess and "x" as a flag, so it becomes: x86-32l-x
In comparison, good ole i?86 is just x86-32l and x86_64 is, well, x86-64l.
There was a problem hiding this comment.
Oh I see. That makes more sense.
noarch -> arch dependencies are technically a different problem than this is trying to solve, for which we simply don't have any good solutions atm. Thanks for the reminder though - as is, this would actually the manual soname dependency in the example N times worse because then have to list all the variants. IMO the least worst solution (that works with any rpm version) is to drop the BuildArch: noarch in these cases. |
|
Another random note of the day: %{_isa} macros (and thus the provides too) should actually use the same values as these markers. |
|
FWIW, I opened a new ticket for the noarch -> arch dependency matter, let's discuss that topic there: #3579 I could've sworn we had a ticket or more like five for that already, but couldn't find any. Well, now we do. |
Traditional rpm dependencies have only supported biarch style installations between 64bit and "something else", traditionally of course 32bit. This has been denoted with (64bit) markers at the end of ELF dependency tokens for some 64bit architectures and for others not, and lets a dependency token of a completely different architecture satisfy that of another. This is inconsistent and limiting at best.
Add a new multiarch mode for elfdeps where each ELF dependency token carries an ABI identifier consisting of the base architecture, it's bitness and endiananess, optionally followed by arch-specific flags. v4 packages continue to use the traditional biarch dependencies, for v6 packages we use the new multiarch style. It's possible to generate
both for transition-period compatibility though.
The last patch is the where the real interest is, the earlier ones are just preliminaries to make this all nicer by converting it to use C++ facilities. There are no docs and the exact format is subject to change, but posting a draft PR to allow experimenting and hopefully inviting a wider community discussion on this.
Fixes: #2197