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:


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

Reply via email to