On Wed, 2022-09-28 at 17:59 -0400, Zack Weinberg wrote:
> On 2022-09-28 5:30 PM, Ansgar wrote:
> > On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote:
> > > "Available and usable at all times" is orthogonal to "maintainer
> > > scripts
> > > do not render the system unbootable".  As I read things, *all*
> > > packages
> > > bear the responsibility of not rendering the system unbootable.
> > 
> > No, it's a significantly weaker requirement than what you want to
> > impose. If it is not available and usable at all time, it can
> > clearly
> > render the system unbootable (by not being available or usable at
> > boot).
> 
> The vast majority of Debian packages provide programs, libraries,
> etc. 
> that are not used at all during the boot process.  Therefore, *even
> if* 
> those packages are currently unusable, due to a crash in the middle
> of 
> an upgrade that left them unpacked-but-not-configured, or whatever,
> they 
> can't prevent the system from coming up at least as far as the point 
> where it's possible to get a root shell and run `dpkg -a --
> configure`.

Yes, those packages are irrelevant and I wasn't talking about them
anywhere. So I don't know why you mention them now.

> The small subset of packages that *are* used at boot time, do need to
> take extra care to keep working even if they are unpacked but not 
> configured, and that subset and that extra requirement is codified as
> the rules for (transitively) Essential packages.

No, that is not correct. The set of packages required for boot is
significantly larger than essential and not well defined.

Common examples include: kernel, boot loaders, init system, ...; they
are often required for boot, but not essential.

I also don't think the essential requirements are sufficient for "works
after system crash".

> But *all* packages must take particular care *in their maintainer 
> scripts* to not render the system unbootable, because maintainer scripts 
> are all run with full root privileges, at a time when the system is in a 
> partially ill-defined state (since it is in the process of being 
> upgraded --

No, they usually aren't run in an ill-defined state.

> this is why we have the "postinst scripts can't assume any 
> non-Essential functionality works" rule),

There is no such rule. Seriously, this is getting nowhere.

If you want to tell maintainers they are wrong and everything they do
must be reverted, please at least inform yourself a bit more before
filing bugs with tech-ctte or vague release-critical bugs. Especially
if you do so for issues where people are already tired of talking
about.

> and yet it could still be in 
> active use (there has never been a requirement to take the system to 
> single-user mode before running 'apt-get upgrade').

That would be a different problem from "must work after arbitrary
system crash". I would prefer if we would not switch between different
problems.

> > I tried searching for that justification and a major internet
> > search
> > provider just says 'Your search - "potentially renders the system
> > unbootable" - did not match any documents.'
> 
> https://www.debian.org/Bugs/Developer#severities
> 
> The official wording appears to be "makes unrelated software on the 
> system (or the entire system) break".  I hope you will agree that a 
> system that doesn't boot is entirely broken.
> 
> https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L79
>  
> is where I got the "unbootable" phrasing.

No, there is a significant difference between "renders the entire
system unusable (e.g., unbootable [...]" and "potentially renders the
system unbootable".

Anyway, please take it to the ctte bug or just close this bug.

Ansgar

Reply via email to