Your message dated Wed, 28 Sep 2022 11:03:56 -0700
with message-id <87a66j4bqr....@melete.silentflame.com>
and subject line Re: Bug#1020792: tech-ctte: Halt merged-/usr transition until
dpkg filesystem damage bugs are fixed
has caused the Debian Bug report #1020792,
regarding tech-ctte: Halt merged-/usr transition until dpkg filesystem damage
bugs are fixed
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1020792: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020792
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
X-Debbugs-Cc: z...@owlfolio.org
I formally request that the Technical Committee call a halt to the
merged-/usr transition until such time as all of the bugs in dpkg that
can, on a merged-/usr system, cause damage to the contents of the
filesystem (e.g. packaged files being silently deleted on upgrade)
have been fixed to the satisfaction of the dpkg maintainers.
## Background
It has been known for some time that dpkg has bugs which prevent it
from correctly handling merged-/usr systems. #858331/#848622 is the
only such bug (that I can find) that has actually been recorded in the
BTS, and it *appears* to be a relatively harmless problem, affecting
only dpkg-query output.
However, Simon Richter <s...@debian.org> showed in
https://lists.debian.org/debian-devel/2021/08/msg00326.html that the
bad dpkg-query output is only the most obvious symptom of a much more
serious problem, and that, under conditions that will plausibly occur
in the archive after the release of bookworm (assuming all continues
as presently planned) upgrading packages on a merged-/usr system can
cause packaged files to disappear from the filesystem. The files most
likely to be affected are the files that are currently packaged in
/bin, /sbin, and /lib, including, just to mention a few, /bin/bash,
/bin/systemd, and /lib/$ARCH/libc.so.6. Thus, the dpkg bugs can
render systems unbootable on upgrade, and should be considered
critical severity.
(N.B. Simon’s message is the only thing I can find that gives
step-by-step instructions to reproduce a problem that could plausibly
cause catastrophic filesystem damage during package upgrades, but the
scenario it describes should _not_ be considered the only problem that
needs to be fixed urgently. Several other equally dire scenarios
are listed in https://wiki.debian.org/Teams/Dpkg/MergedUsr under the
“merged-/usr-via-aliased-dirs” subheading, albeit only tersely.)
Despite the severity of the dpkg bugs having been known since
_at least_ August of 2021, the people working on the merged-/usr
transition have made almost no effort to fix them. A patch exists
(https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=858331;filename=file_move_moratorium.patch;msg=46)
that at least partially addresses the problem, but only one desultory
attempt was made to get it merged.
The people working on the merged-/usr transition have repeatedly
claimed that the several years of experience Debian now has with
systems that were _originally installed_ with merged /usr, and the
somewhat longer baseline for Ubuntu doing the same thing, indicates
the dpkg bugs are not a problem in practice. That claim is incorrect.
The dpkg bugs are *latent* right now because, until the actual release
of bookworm, packages have to continue supporting non-merged systems.
Therefore they cannot move files from /{bin,sbin,lib} to
/usr/{bin,sbin,lib}, which is one of the conditions required to
trigger the most serious known issue (disappearance of packaged files).
I anticipate that if the merged-/usr transition proceeds as planned,
*all systems* that track either testing or unstable will be rendered
unbootable at least once in the bookworm+1 development cycle. This
level of fallout is not acceptable, even in potentiality. Since it
seems clear that the people working on the merged-/usr transition have
no intention of getting the bugs fixed, project-level action is
required.
## Specific actions requested
I ask the Committee to require all of the following, partially
reversing the decision taken in #978636, and overriding maintainers
as necessary:
- The usrmerge and usr-is-merged packages are to be removed from
testing immediately, and severity:critical (justification: “makes
unrelated software break” and/or “breaks the entire system”) bugs
are to be filed to prevent them from re-entering testing.
- Those bugs may not be closed, nor may their severity be lowered,
until *the dpkg maintainers agree* that dpkg can now fully support
merged-/usr systems.
- No package may declare a dependency on either usrmerge or
usr-is-merged until the respective bug is closed. Any packages in
the archive that currently declare such a dependency must drop it
immediately (or else be removed from testing as well).
- No *other* mechanism which converts existing non-merged-/usr
installations to merged-/usr, as a side-effect of package upgrade
or installation, may enter testing, until at least the usr-is-merged
bug is closed. [I can imagine at least one possible resolution
which would make it safe to use dpkg on a system where /usr has
been merged ever since installation, but *not* on a system that was
converted the way the usrmerge package does it.]
- If merged-/usr conversion fails to reach testing before the release
freeze for bookworm, then bookworm shall continue to support
non-merged /usr for its lifetime, and similarly for future
(post-bookworm) releases.
- Optionally: If merged-/usr conversion fails to reach testing before
the release freeze for bookworm, then the installer shall also be
reverted to producing systems without merged /usr [by default], and
it shall remain that way until at least the usr-is-merged bug is
closed.
Thank you for your consideration.
zw
--- End Message ---
--- Begin Message ---
control: tag -1 + wontfix
Hello,
On Wed 28 Sep 2022 at 01:50PM -04, Zack Weinberg wrote:
> On Wed, Sep 28, 2022, at 1:40 PM, Helmut Grohne wrote:
>>
>> So we have systemctl vs systemd and daemontools-run vs runit, both of
>> which declare Conflicts.
>
> *nod* I don't think we need to worry about this when there's a declared
> package-level conflict.
>
>> Depends on whether you consider that one-liner above tooling I guess.
>
> Good enough for now, probably -- it would be nice to have some automation
> searching for such overlaps in packages that *don't* declare Conflicts, and
> filing bugs, but I won't call that a blocker.
>
>> Do you see any other issues?
>
> Not at present, but I'm not the person you should be asking! The only person
> who could possibly say "yeah, the rules in place are sufficient to prevent
> problems post-bookworm until the bugs are actually fixed", with the level of
> confidence we need before proceeding with this transition, is ... the dpkg
> maintainer.
Closing for now, then. If you do find something concrete and file a
bug, please X-Debbugs-CC debian-ctte.
--
Sean Whitton
signature.asc
Description: PGP signature
--- End Message ---
