On Fri, 2 Aug 2024 at 18:01, Russ Allbery wrote:
>
> Simon McVittie writes:
> > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> >> Luca Boccassi writes:
>
> >>> It is correct as-is. VERSION_ID is meant to identify a release, not
> >>> updates or point releases. A release as in, Debi
> "Luca" == Luca Boccassi writes:
Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote:
>>
>> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
>> > To further clarify why the status quo with
>> VERSION_CODENAME=trixie in > sid is really bad: it used to be
Hi Luca,
On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> 1) The os-release specification must be adhered to, and it must be
> possible to tell the difference between testing vs unstable, and each
> must be correctly identified by the respective metadata
Given the state of discuss
Hello,
On Fri 02 Aug 2024 at 12:19pm +01, Luca Boccassi wrote:
> Sorry, but there's no other way to define this than a bug. Well, there
> are many more I could mention, but then Russ would whip out the cane
> ;-)
Russ is not the only person who finds interactions with you difficult.
Please don't
Hello,
Luca is the upstream maintainer of the specification, but whether and
how the specification as published applies to Debian is not simply up to
his assertion.
The TC is being asked to override how Santiago has determined the
specification applies to Debian.
The Release Team's opinion is as
On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
> The TL;DR: ensure that the version of the 'os-release' package with
> the content for unstable stays in unstable and never migrates, and the
> version of the 'os-release' package with the content for testing goes
> to testing either v
On Thu, Aug 01, 2024 at 12:06:21PM -0700, Russ Allbery wrote:
> The second thing that I'm not fond of is giving testing the version number
> 13 when we plan on using 13 as the version number for the trixie release.
> I fear that if we do that, someone (probably a third-party package
> provider) wil
On Thu, Aug 01, 2024 at 11:51:45PM +0200, Helmut Grohne wrote:
> Conversely, I am unsure how to distinguish testing and unstable myself.
> Say I operate an unstable system and eventually decide that my ride is
> too bumpy and I prefer running testing, I may edit my sources.list and
> after a month
On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> The second [objection from the base-files maintainer] is pushing forward a
> philosophical explanation according to which testing and unstable are
> not actually different images, but they are one and the same (two sides
> of the same co
On Thu, 01 Aug 2024 at 20:00:40 -0700, Russ Allbery wrote:
> I just know that I've seen a lot of code that uses version
> numbers or code names this way, mostly in things like Puppet rules. Most
> of the time people will probably get this right, but there are some
> obvious potential mistakes such
On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > It could be a dependency of something else, or it could be marked as
> > essential itself, given the content is a 5 lines text file and a symlink
> > it shouldn't be too hard to figure out an acceptable way to ensure
On Fri, 02 Aug 2024 at 10:31:29 +0200, Marc Haber wrote:
> On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote:
> > I could echo "ID=windows 3.1" into my local
> > /etc/os-release and nothing would stop me or fix it until the next
> > stable release.
>
> Not even automatically. /etc/os-r
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
On Fri, 2 Aug 2024 at 10:09, Simon McVittie wrote:
>
> On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> > The second [objection from the base-files maintainer] is pushing forward a
> > philosophical explanation according to which testing and unstable are
> > not actually different ima
On Fri, 2 Aug 2024 at 10:15, Simon McVittie wrote:
> The closest equivalent of what Fedora and Ubuntu do would be to label
> both testing and unstable as though they were some sort of Debian 13
> prerelease, but not distinguish between the two. But Luca is asking for
> unstable images/chroots/inst
Hi,
With my jaunty TC member hat on, I would prefer if issue came to us with
a description of both sides' perspective on the discussion that they
would view as fair. In any case, I hope that Santiago will feel able to
chime in with their perspective.
My initial thought is that this is really
On Fri, 2 Aug 2024 at 11:39, Matthew Vernon wrote:
>
> Hi,
>
> With my jaunty TC member hat on, I would prefer if issue came to us with
> a description of both sides' perspective on the discussion that they
> would view as fair. In any case, I hope that Santiago will feel able to
> chime in with t
On Fri, 2 Aug 2024 at 11:35, Luca Boccassi wrote:
>
> On Fri, 2 Aug 2024 at 10:15, Simon McVittie wrote:
> > So I think Luca really has two distinct change requests here, not just one:
> >
> > 1. Label testing as Debian 13 starting from the beginning of the trixie
> >cycle, and the equivalent
On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
> VERSION_CODENAME=trixie was added, and the problem as explained is
> that it's present in sid too. So the only identifier we have in sid,
> identifies it as trixie, which is categorically and unequivocally
> wrong.
When involved in a di
On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> To further clarify why the status quo with VERSION_CODENAME=trixie in
> sid is really bad: it used to be that if you had "debian" mentioned in
> os-release but no other version identifying fields, you knew you were
> on testing OR unstab
On Fri, 2 Aug 2024 at 12:48, Simon McVittie wrote:
>
> On Fri, 02 Aug 2024 at 11:35:54 +0100, Luca Boccassi wrote:
> > VERSION_CODENAME=trixie was added, and the problem as explained is
> > that it's present in sid too. So the only identifier we have in sid,
> > identifies it as trixie, which is c
On Fri, 2 Aug 2024 at 13:00, Simon McVittie wrote:
>
> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> > To further clarify why the status quo with VERSION_CODENAME=trixie in
> > sid is really bad: it used to be that if you had "debian" mentioned in
> > os-release but no other versio
On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne
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
> > b
Luca Boccassi writes:
> That's yet another Debian-specific workaround. The point of this is,
> again, answering the question "what is this vendor tree" _without_
> distro specific kludges. That's the entire reason for os-release to
> exist. If the answer at any point is "check os-release AND THEN
On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> Luca Boccassi writes:
> > It is correct as-is. VERSION_ID is meant to identify a release, not
> > updates or point releases. A release as in, Debian Bookworm, or Fedora
> > 40, or Ubuntu Noble, and so on.
>
> Why would you not want to i
On Fri, 2 Aug 2024 at 17:07, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > That's yet another Debian-specific workaround. The point of this is,
> > again, answering the question "what is this vendor tree" _without_
> > distro specific kludges. That's the entire reason for os-release to
> >
Simon McVittie writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>> 40, or Ubuntu Noble, and so on.
>>
27 matches
Mail list logo
