RFE: multi-arch dependencies

[pmatilai]

The current dependency design comes from nineties and the multilib support (those dreaded (64bit)() postfix markers on dependencies) from the early millenium was always an ugly hack, necessiated by backwards compatibility. It's not so much a technically complicated change as it's a compatibility issue, there hasn't been a good time to make such a change. The oncoming rpm v6 format provides a nice point to reset the dependency namespace, but we could and should make the option available before that.

#1038 is a PR in this direction, but there are further details to consider wrt storage and otherwise.

[pmatilai]

PR #1038 suggested appending the entire arch as a marker to the extracted sonames, eg libfoo.so.1()(x86_64) but I dislike it as it pollutes the dependency name, making it unnecessarily hard to query for.

Just this morning it dawned on me that perhaps we could place the architecture into the EVR string instead, ie the above example would become libfoo.so.1 = x86_64. This allows the dependency to be used both in arch-specific and arch-independent manner, depending (pun half intended) on the situation, whether when querying in dependent packages.

One potential issue is that old 32bit packages would now match anything at all, but that should be workable with a new rpmds flag to indicate arch specific, and not letting such dependencies match any provides without a matching flag, which the old packages wouldn't obviously have. Equals (or not) is the only relevant comparison for this kind of "EVR" of course.

Thoughts? Downsides I'm not seeing? Multiple different versions of a provide is not something we commonly have so there may be gremlins related to that.

Turning Neal's patch from #1038 into this is just a couple of lines: pmatilai@046625c (in case people want to play around with it)

[Conan-Kudo]

Thoughts? Downsides I'm not seeing? Multiple different versions of a provide is not something we commonly have so there may be gremlins related to that.

Actually, why don't we do this for adding the actual version for soname dependencies? I don't think it makes sense to use the arch this way, because it makes versioned sonames potentially unreliable.

I think that's why we never did this before, and that was one reason I didn't change it to an EVR string in #1038.

[pmatilai]

Do you mean the soname version or symbol versions? In either case though, the problem is they look like versions but are nothing like rpm versions at all, only equivalence matters so it'd just be confusing a plenty. Also the soname version is a literal part of the string programs link against and breaking that up would only make matters more difficult.

[Conan-Kudo]

I mean something like this: libfoo.so.1 = 1.2.3-4. Debian actually does this in their symbol files, which allows packages to determine what minimum version alongside a soname they need.

[pmatilai]

Interesting, I didn't know that. It's an idea. Of course, arch in dependency version is also just an idea that does have some desireable qualities over something else, but also downsides and limits.

Anyway, before any actual decisions we need to come up with actual list of requirements and goals for the multiarch support and then see how to best achieve those, so these ideas are more like food for thought until then.

[pmatilai]

Okay, this is not going to make it to 4.20. But, we need to start looking into this soon - shortly after 4.20 is branched to not be in this same situation one year from now.

[pmatilai]

For one thing, we need to have a spec for the new format first, and only then implement it. Using #1038 as a starting point:

• ELF dependencies are tagged with arch information in parentheses after the main dependency token
• the arch info is formed as (not necessarily in this order)
  • shorthand name of the architecture
  • for architectures with configurable big/little-endian, the endianess is included
  • other ABI points to consider, somehow generally:
    • soft/hard floating point
    • different address/instruction size (ARM thumb, x32, IIRC some MIPSen etc)

Basically: something like <token>[(<version>)](<archinfo>), note (version) being optional and without the parentheses if there's no version.

We'd like to keep the archinfo as short as possible for space and aesthetics reasons, so it makes sense to optimize the notation for the common case and let the oddballs suffer. Such as:

• almost everything is little-endian so maybe only encode the endianess in the name for big-endian
• soft FP is a very rare thing these days, that's the exception that should be encoded if at all - I know it's a thing you need to care about on Arm, at least in the past, but is it something that needs to be in every single dependency, really?
• have a common notation for the case where address/instruction size differs, like arm thumb and x32, to make us not weep inside (too much)

[Conan-Kudo]

soft FP is a very rare thing these days, that's the exception that should be encoded if at all - I know it's a thing you need to care about on Arm, at least in the past, but is it something that needs to be in every single dependency, really?

We may need to care about it again with RISC-V.