Rework the descriptions of directories for shared libraries and the symlinks to them#218
Rework the descriptions of directories for shared libraries and the symlinks to them#218keszybz wants to merge 4 commits into
Conversation
|
There's one more commit from @behrmann to describe what happens in Arch. PTAL. |
|
The are still some places in the doc that only mention the Debian multiarch layout. Search for Also, in the newly added section, should the section for the more common multilib layout go first? |
Indeed. I adjusted the text in three locations.
I think it's fine as-is. We are explicitly not saying that one is better than the other, so the current alphabetical order is fine. |
This "rewrite" mostly rearranges the existing text and does some minor corrections, but does not introduce changes to the meaning of the spec. The old text was initially written to describe multiarch systems, and was later extended to describe multilib systems, by adding exceptions and clarifications in various places. As a result, it didn't describe either case very well. Users will primarily be interested in one layout or the other (whatever is used by their system), so the text becomes easier to read if the two layouts are described in separate subsections. > /usr/lib/ > Static, private vendor data that is compatible with all architectures This part was actually wrong. /usr/lib/ contains a lot of stuff that is architecture-specific. Also, the data is not "private" in any meaningful way. Shared libraries in particular are … shared. But plenty of other files are used by multiple consumers too. The descriptions for ~/.local/lib* and /usr/lib*/<package> are adjusted accordingly. The description for /usr/include/<arch-id> is tweaked to say that it only applies to multiarch systems. The description of /usr/share is modified to follow the change that was done in 1f621b3 in the other location. Co-authored-by: Jörg Behrmann <behrmann@physik.fu-berlin.de>
We described those symlinks as legacy, but they are part of the ABI, and are not going away. The symlinks themselves are not legacy, the original directories were, but we are describing the symlinks not the old layout. In a multiarch layout, /lib64 does not point to $libdir. It points to a directory with loaders (or more likely symlinks to loaders) for different architectures. The premise of multiarch is parallel installation of multiple architectures, so pointing to a single architecture (either the primary architecture denoted by $libdir or any other) would be incompatible with that.
This document inherited the recommandation for multiarch from its precedessor, the file-hierarchy man page. The multiarch layout _is_ elegant and flexible, but it hasn't been widely adopted, it is only used by the Debian family of distributions. At this point, it doesn't seem likely that it'll be adopted elsewhere. Wiring up installations in this more complex scheme if much more effort. The ability to support multiple architectures from a single installation was more useful when installations were shared. Nowadays, small, tailored images are used much more often. In particular, for immutable installations, the size of the image creates a pretty significant cost, so installations that are trimmed down to support just one architecture make sense. Users who want to run something on a different architecture will probably download a full image and spawn a VM. We shouldn't say that multiarch is the future, or recommend it for "new" installations. New distro efforts are not doing this and we shouldn't be trying to convince more gullible readers to try this.
rpm-based distros and Arch handle multilib differently with one shipping /usr/lib64 and the other shipping /usr/lib32 and therefore /usr/lib containing different widths among the two. This adds a split that describes both situations.
|
i am not convinced about much of this, this just describes the status quo, but does not provide guidelines for the future, for doing it right. While that might be interesting to some i don't think it's useful for a spec. it's descriptive not prescriptive. i.e. what i am getting from this is that this makes lib32 and lib64 a recommended thing, pretends it was a pinnacle of good design. although it's actually just a hack if you ask me. lib64 should exist for compat with the dynamic loader, but otherwise the only reason why anyone would have that would be compat with traditional fedora-based distros, but that doesn't have to be in the spec, people can just add that on their own implementations. the original spec made clear that extensions where allowed in particular for compat and lib32/lib64 could be considered covered by that. I am really not convinced by lib32/lib64 deserves any recommendation here. also a spec that says anything goes (i.e. blesses both multilib/multiarch, without judgement) might as well not exist, because it just describes, it doesn't mandate or recommend anything. maybe split this up? i.e. one descriptive "research" doc that just describes what fedora, suse, debian, arch do, and a separate one that makes a prescriptive recommendation like the original spec did? then i can ignore the research doc, and shut up about complaining about it? |
|
i mean, the libexec/ stuff is similar: there's really no point in having it. fedora has it, i think it should just die because it doesn't bring any benefits. the spec at leasts says that it should not be used. i think lib64 is very similar: it's not a good design. we should mandate the /lib64/ symlink but otherwise not recommend it as anything, because it's a mess. |
The changes are mostly descriptive because there were a few people who asked for that and, if I remember correctly, also asked why multiarch was prescribed. I have little preference there, but recommending multiarch seems… in lack of a better term, untimely? Debian adopted multiarch around 2012, if I remember correctly, and I don't think many distributions have sprung to adopt it since, so there is Debian world with multiarch and the rest. multiarch does seem like the better design, but it lacks adoption outside of Debian land and I don't think recommending it here will change that. I think the question is: What to recommend? Is recommending multiarch still timely or would this be approached differently today? |
I seriously considered this now, but I don't think it's a great idea. For two reasons. First, I want people to use this spec and take is seriously in packaging guidelines and such. This means that it must describe a practical system. If we remove any discussion of multiarch/multilib, the utility of the text goes way down. In practice, all distributions cater to mixed-arch installations. If the text is split, then people have to say "uapi.9 + the second document that actually describes what we do" and nobody wants to do that. Second, the parts that would be split out is
This is what the text did before this commit and this is what the text is doing after this commit. The change was to fix the statement that it should be linked to $libdir, which is completely wrong, as described in the commit message.
There are two categories of "unneeded things": things that are actively broken and things that are more in the bikeshed category. For example
In practice people are going to follow the layout that their distro has. Changing from one to the other is an insane amount of work. If you want, we could recommend one of the variants. Previously we recommended the multiarch layout, but didn't even get its description right. Fedora-style multilib is the most popular. IMO the Arch-style multilib is more elegant… |
|
What is the target audience of the document? |
7 participants
The first commit was the initial motivation: the description of multiarch and multilib was edited too many times and was rather confusing to read. It also contained some incorrect statements. The other two commits are cleanups for the surrounding text. Each has an extensive description in the commit message, not repeated here.