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

On Mon, 5 Aug 2024 at 09:39, Marc Haber <[email protected]> wrote:
>
> On Mon, Aug 05, 2024 at 09:25:31AM +0100, Simon McVittie wrote:
> > * Some package, let's call it foobar, reads os-release and changes its
> >   behaviour according to whether it sees trixie/testing or unstable
> >
> > * foobar_1.2-3 is in unstable and works correctly there
> >
> > * The testing migration scripts let it migrate
> >
> > * trixie's os-release is different from unstable's (this is the essence
> >   of what Luca is asking for)
> >
> > * Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves
> >   incorrectly
> >
> > * Now our mechanisms to avoid regressions in testing have failed to
> >   prevent a regression, because the regression was never visible to users
> >   of unstable, and in fact didn't exist until foobar migrated
>
> That can happen the same way when a package trips over VERSION and
> VERSION_ID suddenly appearing.
>
> While you have a point here, I think that the current state is an
> expression of us valueing our toolchain and processes higher than the
> needs of users of testing. By having our development repositories out in
> the open we are literally inviting people to use it. In fact, that's an
> important part of our QA. We should not make life harder for those
> people.

That, and also this objection assumes it's impossible to tell them
apart right now. It's not, as already shown many times, it just
requires to open code annoying Debian-specific workarounds. But if
anybody wants, they can do it. I know, because I do it in many places
already.