|
|
Subscribe / Log in / New account

Debian still having trouble with merged /usr

Debian still having trouble with merged /usr

Posted Apr 10, 2022 5:32 UTC (Sun) by rra (subscriber, #99804)
In reply to: Debian still having trouble with merged /usr by jond
Parent article: Debian still having trouble with merged /usr

Luca and I have an architectural disagreement and I'm not sure which of us is correct. It's very much an arguable point.

I assume Luca is correct that Ubuntu hasn't encountered any problems (I don't follow Ubuntu development so have no personal knowledge). The edge cases where there are failures are, well, edge cases, and pretty uncommon ones as well, although they do turn up from time to time. I think it's entirely plausible that Ubuntu just hasn't happened to encounter one of those edge cases but that Debian will in the future; Luca thinks that Ubuntu does enough original packaging including moving files between packages that if the problems were at all common, Ubuntu would have seen them, and thus Debian won't run into them in the future. It's really hard to tell which of us is correct. It's mostly guesswork, and I cede the point that Luca has more concrete data.

My philosophical position rests on a desire for a stronger correctness goal. I think a package manager should be like a file system: short of hardware failure, it should never lose data ever, period, for any reason, no matter how rare the circumstances are. Anything else is a bug that should be fixed, and treated fairly seriously. This is a very strong position. It's entirely legitimate for Luca to not agree and think I'm holding the package manager to too high of a standard.

Philosophically, I think Debian should be a project that pays attention to those sorts of details, and that we should fix this sort of bug even if the incidence is rare. But I'm also not in a position to volunteer to do the work.


to post comments

Debian still having trouble with merged /usr

Posted Apr 10, 2022 9:19 UTC (Sun) by bluca (subscriber, #118303) [Link] (5 responses)

My main point is that we are blocked, upstream software is starting to plan dropping support for legacy split-usr, and there's no other clear way out. Dpkg can be fixed _eventually_ but it doesn't need to be fixed immediately. There's no urgency. And whatever fix eventually comes has to apply to an already switched system, because Ubuntu exists and cannot be broken, given it's already fully switched. This is what happens when one delays making (and implementing) decisions again and again: eventually others move ahead without you, and you aren't left with many choices.

Debian still having trouble with merged /usr

Posted Apr 11, 2022 0:18 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

Do you have some examples of upstreams that are dropping support for split-usr systems?

Debian still having trouble with merged /usr

Posted Apr 11, 2022 5:58 UTC (Mon) by johannbg (guest, #65743) [Link]

It's been what more than a decade now since the initial push to clean this artifical mess up on the core/baseOS level which should be way more than enough time for downstream distributions to adapt.

There is literally no technical reason to support systems with split-usr and supporting the split-usr mode makes both code and documentation more complicated for upstreams ( it adds to the CoD for projects ).

Upstream will and should at this point in time close any such issue with wontfix and consumers of components that make up the core/baseOS layers should rather expect that split-usr mode is not supported or no longer supported and upstreams will drop this without hesitation or as much as a warning at this point. ( not that such warning would ever be visible to anyone other than the person building the software anyway like [1] )

1. https://github.com/systemd/systemd/blob/main/meson.build

Debian still having trouble with merged /usr

Posted Apr 11, 2022 2:29 UTC (Mon) by rra (subscriber, #99804) [Link] (2 responses)

The point that one cannot have problems once every system has been switched is a good one. I'm not sure that's 100% correct, but I think the only way it could be incorrect is if someone has held packages from before the /usr merge, and then later upgrades them in a way that involves files moving between packages. This makes the edge case even rarer.

Maybe this really would be a sufficiently rare situation provided that Debian was careful not to move files between / and /usr for one release after usrmerge became mandatory (assuming we do make usrmerge mandatory).

I will say that I am still uncomfortable leaving dpkg with an incorrect understanding of where files are on the file system. That seems like the sort of thing that will cause problems even if we don't know what problems they are and aren't running into them now. But I admit this is philosophical and code smell, rather than me being able to point to a specific issue other than the one we already know about when files move between packages.

Debian still having trouble with merged /usr

Posted Apr 11, 2022 7:29 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 responses)

After /usrmerge, dpkg's understanding is "stuff is in /usr/* instead of /*" (assuming that the database reader is patched to adjust merged paths on the fly). Which is factually correct.

IMHO these oh-so-dangerous edge cases simply do not occur on actual systems. Files from held packages get moved to /usr by the usr-merge transition, they are where dpkg thinks they are (see above) and are reachable under both old and new paths, due to various symlinks.

Debian still having trouble with merged /usr

Posted Apr 11, 2022 17:15 UTC (Mon) by rra (subscriber, #99804) [Link]

> assuming that the database reader is patched to adjust merged paths on the fly

You're assuming exactly the thing that we're discussing, which is not done, and which the dpkg maintainer does not want to do. Yes, if the problem is solved, there isn't much of a problem.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds