Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On 2022-09-27 10:26:36 -0400, Zack Weinberg wrote: > On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote: > >> I'd like to make sure that the bug submitter has not identified > >> something new here. > > > > I've not seen any new issues appearing since the last round I file bugs. > > I wasn’t aware that you have been filing bugs related to the > transition. What criteria are you using to find and file those bugs? I only checked for packages violating the moratorium. Thankfully a check for that was implemented by Luca in piuparts. If we have additional patterns that could cause issues for upgrades, the check would ideally be extended with that information. Cheers -- Sebastian Ramacher
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On 2022-09-26 14:49:15 -0600, Sam Hartman wrote: > >>>>> "Sean" == Sean Whitton writes: > > Sean> - you might be lacking the full context of TC-involving > Sean> discussions over the past few months, but so far as I can see, > Sean> you are asking for us to undo a decision that we only just > Sean> made, which doesn't make sense. > > Sean, as someone who has tried to follow this for a while, I'm confused > by a third thing. > Doesn't the TC recommendation given additional weight by the RT that we > not migrate file paths until the dpkg bug has been fixed make it > impossible for the pre-conditions for disappearing files to happen? Indeed, there is a moratorium in place for this case. > I'd like to make sure that the bug submitter has not identified > something new here. I've not seen any new issues appearing since the last round I file bugs. Cheers > > >Also, to the bug submitter: > >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.) > > I think that if you are going to ask for drastic action like you are > doing, a turse mention on a wiki page is not sufficient documentation. > Simon's mail got significant attention because he actually worked > through and documented the situation. > I and I believe several people who have looked at this situation believe > that the RT guidance will prevent the issue Simon raised from happening. > > I suspect that if someone were to clearly document a different situation > that had not previously been considered, people would look at it. > I'd hope the TC would be open to considering newly documented technical > problems as an example. > But because the decision has been made, the bar for blocking things is a > lot higher at this point than turse descriptions on a wiki page. > -- Sebastian Ramacher
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On 2022-09-27 09:23:47 +0100, Matthew Vernon wrote: > Hi Zack, > > Thanks for bringing this to the committee; even if Sean is correct that we > won't act on this report, you've described the issues clearly and I think it > was worth bringing to our attention. > > On 26/09/2022 20:28, Zack Weinberg wrote: > > > 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. > > This much is uncontroversial. > > > However, Simon Richter 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. > > This is a very useful message, and (at least to my mind) makes it clearer > how more serious problems might well occur. > > As Sean says, though, questions of what are and aren't RC bugs are typically > the domain of the release team, not the TC. > > I don't think you're asking us to revisit our decision on the approach taken > to merged-/usr; we don't generally return to a decision once made (and a GR > would normally be the approach to overturning a TC decision). Personally, I > think there are circumstances where we might (e.g. a convincing argument > that we missed something critical in our decision-making, or that > circumstances have changed sufficiently to warrant another look), but I > don't think we are in that situation here at the moment. > > I think the best way to proceed would be to open a bug describing the > problem that Simon outlines with RC severity; the relevant maintainers and > release team can then discuss how to resolve the issues and if they warrant > delaying the release or adjusting when we complete the transition. Obviously > those people might want to ask the TC for advice, but I think that would be > up to them at least in the first instance. Is there a package in the archive that has this issue? If so, can you point me to a bug report? Cheers -- Sebastian Ramacher
Bug#994275: Reverting breaking changes in debianutils
Hi Simon On 2021-10-11 01:01:45 +0100, Simon McVittie wrote: > On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote: > > The release team has so far protected users of testing from the > > problem by blocking testing migration, but this is not a long-term > > solution. > > Adrian asked in #994275 for changes in several topics to be reverted: > > - which(1) deprecation > - deprecation warnings on stderr > - management via alternatives > - possible future removal > - tempfile(1) removal > - installkernel(8) moving from /sbin to /usr/sbin > - run-parts(8) moving from /bin to /usr/bin > > Which of those topics were your reason for adding a "block debianutils" > hint? Are there any of those topics whose resolution you would consider > to be a prerequisite for letting debianutils migrate to testing again? I don't care about which(1). My reason for blocking debianutils was the tempfile(1) removal, but I suppose now I would add the last two points to the list as well - but usrmerge is the topic of another CTTE bug anyway. > The hint references #992399, which is related to tempfile(1), but > #992399 has been closed (via a merge with #992396, which was resolved by > debianutils adding a versioned Breaks on x11-common versions that needed > tempfile). Do the release team consider #992399 to have been adequately > resolved, or do you consider debianutils to still have a RC bug? I don't consider #992399 to be fixed. I specifically asked for a coordinated transition for the tempfile removal in that bug. So far I see no indication that this transition is coordinated in any way. As far as I can tell, the current strategy is to hope that users of unstable install a large enough set of packages to discover all the remaining uses of tempfile in maintainer scripts. See #993621, #994877, #996099 (which I just filed after a grep for tempfile in /var/lib/dpkg/info) for the latest examples. I think it would have been easy enough to follow a more systematic approach by processing the whole archive with piuparts to detect all the remaining cases. Additionally, Debian Policy 10.4 and the lintian tag possibly-insecure-handling-of-tmp-files-in-maintainer-script still recommend "tempfile or mktemp". Beyond tempfile(1) in maintainer scripts, random uses of tempfile are still being reported. See #995583 for the latest example. But also for this case, I see no coordination. > If debianutils reinstated tempfile(1) in bookworm, and removed it in > testing/unstable after the release of bookworm, would the release team > consider that to be an adequate transitional period? Helmut has shown how to remove interfaces from the essential set with e2fsprogs. But I think e2fsprogs was in a much better place when this was done: the interesting interfaces were moved to util-linux and for the remaining users of e2fsprogs it was easy enough to add dependencies. tempfile(1) however is used in maintainer scripts with the potential for upgrade failures. At least for that case I would expect that all the users are fixed in release $x and then tempfile could be removed in $x + 1. For all the other uses of tempfile, I'm currently lacking an overview. Cheers > > Thanks, > smcv -- Sebastian Ramacher signature.asc Description: PGP signature
