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.
Attachment:
signature.asc
Description: PGP signature