- This topic has 8 replies, 5 voices, and was last updated Sep 3-8:58 pm by Brian Masinick.
-
Posts
-
Brian Masinick
The following comes from the Debian Release Team. It describes a concern and a risk regarding the location of packages and the behavior of the dpkg command. Since a lot of what we do (even outside of “SystemD” concerns) depends on Debian packaging tools, this will most certainly impact any software we use that depends on Bookworm behavior; hopefully this will be “properly” resolved in time for the Bookworm (and our antiX 22 release):
Dear all,
Although we don’t particularly like the need to make a statement, the
Release Team feels obliged to make the following statements about
merged-/usr.* When we’re talking in this mail about the merged-/usr transition or
forced migration we are talking about the (automatic, opt-out)
mechanism that during upgrades from bullseye to bookworm will
migrate the system to a merged-/usr filesystem layout as defined in
[1].* The Release Team is of the opinion that Debian’s merged-/usr project
is only finished when dpkg supports it. We prefer dpkg to be fixed
before the bookworm freeze starts, however this does not block the
forced migration.* We recommend coordinating the upgrade migration mechanism sooner
rather than later. I.e. inform and agree on timing between the
upload to unstable and infrastructure maintainers that need to
ensure that their infrastructure opts-out of the merge.* We will not delay the release of bookworm for the absence of an
implementation of the forced migration upon upgrades. We consider
the forced migration a special transition. The migration to testing
needs to happen before the Transition and Toolchain freeze or it
will not be part of bookworm.* The TC resolution #994388[1] recommended a moratorium on moving
files’ canonical location from / into /usr. Until there’s support in
dpkg for merged /usr, we want this moratorium to remain in place,
even after the bookworm release. Files moving their canonical
location between / and /usr (details in [1]) *and* from one binary
package to another binary package within one release cycle remain an
RC issue unless dpkg supports it.* If the forced migration makes it into bookworm in time, then
non-merged-/usr root filesystems are officially not supported after
the release of bookworm, except during the upgrade. If the forced
migration implementation misses the freeze deadline, bookworm
officially supports non-merged-/usr root filesystems.* For the bookworm release, time is running short.
On behalf of the Release Team
Paul[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110
--
Brian Masinick
andyprough
If anyone could translate this into simple English, I would appreciate it. I’m pretty sure I understand the concept of a canonical path as I run into this when writing linking commands, but I don’t quite get what is being referred to as “merged /usr”.
sybok
Hi, the text at the beginning of the following link explains it https://wiki.debian.org/Teams/Dpkg/MergedUsr
olsztyn
text at the beginning of the following link explains it
I am not an expert but this direction looks good to me – clean up the existing mess in Linux directory structure. If I remember, Intel’s Clear Linux did just about the same and also they eliminated /etc from system use. I used to use Clear Linux until some year ago…
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersBrian Masinick
A reasonable thing for the Debian project to do is to require that every package place all code beneath the /usr file system. There can be any number of subdirectories beneath /usr.
Only /boot, /etc, /usr and /var belong under / for consistent behavior. There is work to do, but if each maintainer rebuilds their code it’s possible and not horribly difficult either, though as far as the project goes it’s a major endeavor.
--
Brian Masinickandyprough
Oh goodness – this sounds like it could be a big mess during the transition. Hope it goes smooth, and I hope Debian doesn’t allow the change until any problems have been ironed out.
iznit
If anyone could translate this into simple
quoting “[1]” linked in the OP
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110
libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
such as lib64 on the amd64 architecture.Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
/libQUAL that exists are symbolic links to the corresponding directories
below /usr. This results in aliasing between /bin and /usr/bin, and so on.The page linked to by sybok, it describes the rationale supporting the change to merged /usr
Some (not necessarily all of) the ongoing current “problems” related to dpkg command:
inaccurate output from “dpkg -S” because dpkg [[[does not clarify]]] any symlinked directory objects
certain dpkg operations result in undesirable file(s) deletion during moves
iznit
link explains an example of “merge” related security problem
scroll to page section “Problems with R” for another described example
The dpkg page of debian wiki has been updated as recently as 2 weeks ago.
Just read the one paragragh for the “broken-usrmerge” wiki page scetion.
https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmergeBrian Masinick
link explains an example of “merge” related security problem
scroll to page section “Problems with R” for another described example
Given the history that iznit has shared with us, we’ve seen this move proposed, and even attempted, but it’s been backed out every time.
On the other hand, at least one distribution cited in this thread has performed filesystem hierarchy cleanup, and relatively new distributions have also emerged that have modified their approaches. Some, on occasion, simplify things; at least half of them are just “different” or further complicate matters for reasons that only their developers and major followers understand.It’s debatable whether any of the three latest Debian proposals will proceed anywhere past the proposal stage.
In my opinion, what might actually make sense, since we’ve seen them before, is to create a respin of Debian, make it public, but keep it a respin.
If and only if it finally solves the problems, then make the respin become the main version, and flip the previous main version into a respin that’s available for anyone who can’t or won’t live with the changes.We’ve already seen the Devuan distribution hold onto the sysvinit scheduling method while Debian has long since moved to systemD, and antiX uses the sysvinit and runit in place of systemD, so it CAN be done and it can work side by side with other approaches.
--
Brian Masinick
- You must be logged in to reply to this topic.
