On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote: > On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote: > > Also, as is has been discussed, if the /usr/doc/ transition was > > representative then this would probably take many years. > > You keep using that as an argument. I think it's very disinginuous to > point to a problem Debian had over 20 years ago[1] and say "look, we > don't know how to do this quickly". It's not like things haven't changed > since. > > We can (and should, IMO) declare *today* that for bookworm, shipping > files in / (as opposed to /usr) that are not compatibility symlinks will > be RC. > > You can start writing a lintian check today for the same. > > If we take both these steps, this will only take us one release cycle, > and the dpkg maintainers can come up with a plan to remove /bin and > friends and replace them by symlinks in ways that will not confuse dpkg. > > [1] the /usr/doc transition was in progress when I first joined Debian, > 20 years ago. I don't remember the start of it, but I do remember it > ending. I mentioned this on IRC earlier, but I think it warrants a citation on the list/bug since I don't think it was referenced before. AFAIK, SUSE tried the symlink-farm way (ie: some variation of option 2), and the current status is explained here: https://en.opensuse.org/openSUSE:Usr_merge Some quotes: "A previous attempt of the UsrMerge from 2012 was never finished" "The current state is an inconsistent mess" And this in a distro with a strong governance model behind. If I understand correctly, it looks like they are now attempting to go the usrmerged-way (ie: option 1, or the Fedora-option). All in all, we have 2 real-world case studies. - Fedora tried the usrmerge method, and succeeded - SUSE tried the symlink-farm method, and (it appears) failed Aside from all theoreticals and hyphoteticals, this seems to me to be a pretty important real-world data point to consider when deciding which strategy to adopt. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part