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

On Mon, 5 Aug 2024 at 08:39, Helmut Grohne <[email protected]> wrote:
>
> Hi Luca,
>
> On Fri, Aug 02, 2024 at 04:17:43PM +0100, Luca Boccassi wrote:
> > 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?
>
> No. You need to decide whether /etc/os-release is to be essential or
> not.
>
> If it is, then your proposed dependency in init-system-helpers does not
> cut it, because I can simply upgrade base-files before
> init-system-helpers and then my /etc/os-release is gone violating Debian
> policy. A more reliable mechanism for transitioning essential files is
> required.

Sure, but violating debian policy is something that happens when it's
needed or worth doing, and then it's dealt with if it actually becomes
a problem. In _practice_ I doubt that would create actual issues,
given it requires manually hold back the update of one but not the
other. In practice, a synchronized upload should be more than enough
to avoid real issues. This is something that could be established with
QA effort once it's implemented as POC.