Hi Ansgar, Ansgar dijo [Wed, Sep 28, 2022 at 10:18:26PM +0200]: > Any package relevant for successful boot. Any upgrade. > > As far as I can tell, the submitter requires some guarantees > significantly stronger than what Debian requires for essential > packages. > > In particular, boot-relevant packages are demanded to work in > unconfigured state, with not fully satisfied dependencies (possibly not > even unpackaged?), in partly unpackaged states, after maintainer script > errors, and all of that in combination with system crashes that might > result in partly written data to filesystems. And possibly in other > interesting system states too.
Humm, as the maintainer for raspi-firmware, this definitively addresses an area where I'm responsible. So this is naturally interesting for me even outside my TC role. There is a point I somewhat agree with Bug#1020920's submitter: Packages modifying the packages involved in system boot need to be extra careful to reduce the window of vulnerability for an unbootable system as much as possible. However, no matter how careful we are, I do not think it's expectable that we can guarantee the atomic interaction mode Zack W. suggests — There is no syscall matching "rename and create a symlink". And even if we had one, it would most probably still become two separate filesystem operations in the end. Of course, the supported filesystems' code could be modified so that said operation sequence could be added to the journal beforehand, so they can be effectively considered as atomic, but... That's quite an unrealistic expectation. We cannot expect to implement actions not expressable in the set of primitives Linux exposes to us. We cannot expect a (quite invasive I'd expect) kernel patch to be applied just because we want to run usrmerge. > > (2) The TC is a decision-making body of last resort. The bug you > > mention was filed today. Might this be premature? > > Well, if we close it or don't act on it, people will complain and/or > demand to remove us from Debian for not acting on it (the latter might > be limited to people just sitting on their porch). > > The other tech-ctte bug about usrmerge also suggested it would just end > up here either way. There is a high chance we might end up getting this bug in the TC, given the spirits we have seen around merged-/usr. However, I agree with Sean: This bug is too early to summon the TC. I know that if I suggest you to bring the issue to d-devel@l.d.o it will fuel a flamewar, but I see no other proper way to handle _this particular mail_. Maybe the request could be phrased differently, in a way it could encompass this bug report (i.e. "ask the TC whether we might use sloppy techniques when upgrading, considering the risks we take as acceptable" (of course, I don't mean your job is sloppy, it's just an example text that will not be accepted if asked 😉) So... I'm also inclined to ask you to please close this TC bug, as it is not acceptable for a TC ruling. (Also, how many rulings does it make sense for the TC to hold on the same tired topic of merged-/usr?) Greetings, - Gunnar.
signature.asc
Description: PGP signature