Bug#1077764: Ruling request on os-release specification implementation

Luca Boccassi <[email protected]> Fri, 02 Aug 2024 16:17:43 +0100
Newsgroups	gmane.linux.debian.devel.ctte
Message-ID	<9572f6dbd25c758d21f67576df81e651b86903e1.camel__36021.7601338931$1722612096$gmane$org@debian.org>
On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne <[email protected]>
wrote:
> Hi Russ,
> 
> Let me adress the essential/bootstrap aspects of this sub-discussion
> only.
> 
> On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> > Given that it's included in base-files now and base-files is
essential, I
> > believe it has to continue to be provided by an essential package,
unless
> > we want to try to do the work of figuring out if os-release can be
removed
> > from essential (and I would not be eager to do that).
> 
> I concur.
> 
> > Since it is part of the essential set, though, I'm not sure the
dependency
> > from base-files is actually needed (but also it may not really
matter).  I
> > think dependencies between essential packages are only really used
during
> > the bootstrapping phase, and presumably os-release is not needed by
> > bootstrapping.
> 
> It actually is the other way round. debootstrap-like tools will
> automatically pick up all packages marked with "Essential: yes".
> Bootstrapped systems will not magically install newly essential
packages
> though. So doing an upload of base-files that releases /etc/os-
release
> will not magically cause a newly essential os-release package to be
> installed and thus our essential promise of /etc/os-release may be
> temporarily broken. (There is no implication of how bad breaking this
> promise is.) So whenever we want to add a new package to the
essential
> set, we need some existing essential package to declare a dependency
on
> that new package for the duration of one release cycle (as we do not
> support skip upgrades).
> 
> The obvious candidate to express such a dependency would be base-
files
> here and that brings us back to the aspects you (Russ) mentioned
earlier
> regarding the fragility of the bootstrap order related to base-files.
> Admittedly, bootstrapping is more empirically solved in Debian than
> well-defined. As I attempted clarifying this in Debian policy
earlier,
> the outcome was to explicitly leave it undefined. If I remember
> correctly, randomly ordering the maintainer scripts executed during
> filesystem bootstrap makes things fail every now and then and the
order
> that most tools produce works well enough currently.  Any new
dependency
> inside the essential set poses a risk of perturbing this order that
> happens to work by chance. Hence my request to validate the proposed
> changes.  With luck, things just work, but we better figure out
before
> we upload to unstable.
> 
> This is not pretty, but it is what we have. And then I see this
mostly
> as a work item rather than a blocking issue once we agree on the
other
> matters.

Validating is of course necessary. If the worry is around changing the
dependencies of base-files, I would be happy to carry the dependency on
a new os-release binary package in init-system-helpers, which is
already Essential: yes. I already did something similar in Bookworm to
force all installations to become usrmerged, and I do not recall issues
with the bootstrapping order. This would be even easier in practice as
the new package would have a single file, no maintainer scripts, no
dependencies and no build dependencies. Would that solve your concerns?

-- 
Kind regards,
Luca Boccassi
signature.asc (application/pgp-signature, 833 B)