On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne <hel...@subdivi.de> 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
Description: This is a digitally signed message part
