Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Hi, Am 29.06.19 um 23:32 schrieb Thomas Goirand: > On 6/29/19 3:33 PM, Tomas Pospisek wrote: >> Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: >>> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: TLDR; year based release identifiers should be prefered since they are much more intuitive to reason about than codenames and sequentialy numbered release identifiers. If Debian should improve/change release identifiers, then I'd suggest to ponder a year based versioning scheme (as Ubuntu is using). >>> This only works with Ubuntu because they set the release date in advance. >> >> You assign the year to the release identifier when the release is ready: >> release_id = now().year(). There's certainly some infrastructure stuff >> that needs that release_id that needs to be prepared in advance, but I >> think that can be done pragmatically, when the release is "99%" ready. >> Am I missing something? >> *t [...] > > In some software we have in buster, they already have hard-wired the > names of the 2 next Debian releases. How would you do this with years if > we don't know the release dates in advance? Allow me to start with the inverse question: should the fact that software makes assumptions about the future preclude humans from shaping that future as they deem best? Now what if there was a way to have both: a better naming scheme *and* compatibility with software that hard codes the future? Lets see - one possibility would be to have both year based release identifiers and code name based ones. That could possibly solve both issues (better naming + compatibility). Or maybe there are yet other ways to solve the supposed contradiction? F.ex. updating the hard-coded SW comes to my mind. > Besides this, I very much dislike the way it sounds. :) The way what sounds? *t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Hello, On 30/06/2019 06:53, Alf Gaida wrote: >>> It will confuse me because in 2021 I will expect release 2021 . >>> Furthermore, will .7 stand for July ? >> I assume it's about point releases (which, again, Ubuntu doesn't do >> AFAIK). >> > The keyword will be education - i wrote some times ago: Let people use wht > they are happy with - it will take a blog entry or two to let users know what > 20xy.z means - i can't resist and bring it to the point: > > If there will be a release 2020.0 and 2020.1 - and there will be release > notes - do we really assume our users are to dumb to get it??? I assume that users can understand the current codename scheme used in Debian. And I found it funny when I read for the first time the explanation on the website (there was no blog at this glorious time). If order is a question (which version comes before the other one), we can impose that the first letter of the codenames must fellow the alphabetic order. Jerome > > Cheers Alf > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Another issue is that with a sequential scheme I always know what the next version is whereas if a year based scheme is used without a set schedule the version after 19 may be anything from 19 to 25. Sincerely, Moshe Piekarski -- There's no such thing as a stupid question, But there are plenty of inquisitive idiots. signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). The keyword will be education - i wrote some times ago: Let people use wht they are happy with - it will take a blog entry or two to let users know what 20xy.z means - i can't resist and bring it to the point: If there will be a release 2020.0 and 2020.1 - and there will be release notes - do we really assume our users are to dumb to get it??? Cheers Alf
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 8:16 PM Tomas Pospisek wrote: > Let's seriously consider using year based release identifiers. At this point in the thread it is very clear that which identifier one prefers is very individual and dependent on use-cases. So we should add support for more individuals and use-cases in order to accommodate everyone's preferences. Killing off use-cases by switching between identifier styles isn't the right way to go. I suggest that we add an "Aliases" field to the Release file. Then apt could use that to silence its warnings about sources.list not matching Suite/Codename. Then we could request ftp-master update dak to populate the Aliases field and add symlinks for all aliases. Any volunteers to write the needed patches? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 6/29/19 3:33 PM, Tomas Pospisek wrote: > Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: >> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: >>> TLDR; year based release identifiers should be prefered since they are >>> much more intuitive to reason about than codenames and sequentialy >>> numbered release identifiers. >>> >>> If Debian should improve/change release identifiers, then I'd suggest to >>> ponder a year based versioning scheme (as Ubuntu is using). >> This only works with Ubuntu because they set the release date in advance. > > You assign the year to the release identifier when the release is ready: > release_id = now().year(). There's certainly some infrastructure stuff > that needs that release_id that needs to be prepared in advance, but I > think that can be done pragmatically, when the release is "99%" ready. > Am I missing something? > *t Thanks, but no. In some software we have in buster, they already have hard-wired the names of the 2 next Debian releases. How would you do this with years if we don't know the release dates in advance? Besides this, I very much dislike the way it sounds. :) Thomas
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
在 2019-06-29六的 20:21 +0500，Andrey Rahmatullin写道：
> On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote:
> > > > > As others here I am starting to get confused by the release code
> > > > > names, as are my peers that are not that much into Debian. And
> > > > > sequential release numbers are devoid of any semantics except for
> > > > > their monotonically increasing character.
> > > > [...]
> > > >
> > > > And yet you *wouldn't* be confused when Debian 2019.7 is released in
> > > > 2021?
> > >
> > > That's right, I don't think that'd confuse me. The reason it wouldn't
> > > confuse me, is that I expect releases to be updated eventually and that
> > > can happen at any time in the future - f.ex. in 2021.
> > > *t
> > >
> >
> > It will confuse me because in 2021 I will expect release 2021 .
> > Furthermore, will .7 stand for July ?
> I assume it's about point releases (which, again, Ubuntu doesn't do
> AFAIK).
I'm not sure about other issues but Ubuntu *do* make point releases for LTS.
There's something like Ubuntu 16.04.{,1,2,3,4}, etc. Their corresponding
(point) release dates are, of course, not in year 2016. As a result I think
it's not an issue.
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote: > >>> As others here I am starting to get confused by the release code > >>> names, as are my peers that are not that much into Debian. And > >>> sequential release numbers are devoid of any semantics except for > >>> their monotonically increasing character. > >> [...] > >> > >> And yet you *wouldn't* be confused when Debian 2019.7 is released in > >> 2021? > > > > That's right, I don't think that'd confuse me. The reason it wouldn't > > confuse me, is that I expect releases to be updated eventually and that > > can happen at any time in the future - f.ex. in 2021. > > *t > > > > It will confuse me because in 2021 I will expect release 2021 . > Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). -- WBR, wRAR signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 29/06/2019 17:27, Tomas Pospisek wrote: > Am 29.06.19 um 14:41 schrieb Jeremy Stanley: >> On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: >> [...] >>> As others here I am starting to get confused by the release code >>> names, as are my peers that are not that much into Debian. And >>> sequential release numbers are devoid of any semantics except for >>> their monotonically increasing character. >> [...] >> >> And yet you *wouldn't* be confused when Debian 2019.7 is released in >> 2021? > > That's right, I don't think that'd confuse me. The reason it wouldn't > confuse me, is that I expect releases to be updated eventually and that > can happen at any time in the future - f.ex. in 2021. > *t > It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? Jerome signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: > On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: >> TLDR; year based release identifiers should be prefered since they are >> much more intuitive to reason about than codenames and sequentialy >> numbered release identifiers. >> >> If Debian should improve/change release identifiers, then I'd suggest to >> ponder a year based versioning scheme (as Ubuntu is using). > This only works with Ubuntu because they set the release date in advance. You assign the year to the release identifier when the release is ready: release_id = now().year(). There's certainly some infrastructure stuff that needs that release_id that needs to be prepared in advance, but I think that can be done pragmatically, when the release is "99%" ready. Am I missing something? *t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: > TLDR; year based release identifiers should be prefered since they are > much more intuitive to reason about than codenames and sequentialy > numbered release identifiers. > > If Debian should improve/change release identifiers, then I'd suggest to > ponder a year based versioning scheme (as Ubuntu is using). This only works with Ubuntu because they set the release date in advance. -- WBR, wRAR signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 29.06.19 um 14:41 schrieb Jeremy Stanley: > On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: > [...] >> As others here I am starting to get confused by the release code >> names, as are my peers that are not that much into Debian. And >> sequential release numbers are devoid of any semantics except for >> their monotonically increasing character. > [...] > > And yet you *wouldn't* be confused when Debian 2019.7 is released in > 2021? That's right, I don't think that'd confuse me. The reason it wouldn't confuse me, is that I expect releases to be updated eventually and that can happen at any time in the future - f.ex. in 2021. *t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: [...] > As others here I am starting to get confused by the release code > names, as are my peers that are not that much into Debian. And > sequential release numbers are devoid of any semantics except for > their monotonically increasing character. [...] And yet you *wouldn't* be confused when Debian 2019.7 is released in 2021? -- Jeremy Stanley signature.asc Description: PGP signature
Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 25.06.19 um 08:08 schrieb Ansgar:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
>
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
TLDR; year based release identifiers should be prefered since they are
much more intuitive to reason about than codenames and sequentialy
numbered release identifiers.
If Debian should improve/change release identifiers, then I'd suggest to
ponder a year based versioning scheme (as Ubuntu is using).
As others here I am starting to get confused by the release code names,
as are my peers that are not that much into Debian. And sequential
release numbers are devoid of any semantics except for their
monotonically increasing character.
On the other hand, using year numbers as release identifiers has the
advantage of:
* getting rid of the need to remember arbitrary names and their sequence
* being linked to and rooted in everyday human experience, which makes
it intuitive and easy to reason about releases
When reasoning about an installation of Ubuntu "14.04" one can easily
come to the conclusion, that it's probably wise to upgrade, that release
being 5 years old, whereas an "16.04" might still smell reasonably fresh
and is probalby still OK to run.
Let's seriously consider using year based release identifiers.
*t
Re: getting rid of "testing"
On Fri, Jun 28, 2019 at 11:38:36AM +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: getting rid of "testing""):
> > distro-info-data.deb has this information for Debian and Ubuntu, in a
> > CSV file. It has convenience bindings for Perl, Python and CLI, and is
> > also used by recent versions of Debian's implementation of lsb-release.
>
> TIL! Thank you.
See also:
http://git.trueelena.org/cgit.cgi/software/debdate/about/
http://git.trueelena.org/cgit.cgi/software/debdate/tree/debdate.1.rst
http://git.trueelena.org/cgit.cgi/software/debdate/tree/debdate
:)
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signature.asc
Description: PGP signature
Re: getting rid of "testing"
Simon McVittie writes ("Re: getting rid of "testing""):
> On Thu, 27 Jun 2019 at 12:04:39 +0100, Ian Jackson wrote:
> > [What is currently stable, etc.] is available via the ftpmaster API
> > service, and by reading symlinks
> > in archive mirrors. I think the idea of having this information in a
> > .deb too (ideally kept up to date in all in-support releases,
> > including LTS) is a good one.
>
> distro-info-data.deb has this information for Debian and Ubuntu, in a
> CSV file. It has convenience bindings for Perl, Python and CLI, and is
> also used by recent versions of Debian's implementation of lsb-release.
TIL! Thank you.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: getting rid of "testing"
On Thu, Jun 27, 2019 at 10:16:33PM +0200, Wouter Verhelst wrote: > Yes please, let's use debian11 in the URL somewhere. Because debian11 is such a buzz... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This ⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project. ⠈⠳⣄
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 01:11:09PM +0500, Andrey Rahmatullin wrote: > On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > > Related to that I would like to be able to write something like > > > deb http://deb.debian.org/debian debian11 main > > > deb http://security.debian.org/debian-security debian11-security main > > > in sources.list as codenames confuse people. > > > > Can you please elaborate on the "confuse people"? > I guess only (most?) Debian contributors and hardcore Debian users > remember the order of the codenames and their mappings to current > stable/oldstable/testing and to numeric versions. If even that. Potato was followed by sarge, but I think there was something in between (although I'm not sure). There's an etch somewhere, and a lenny. But what were the orderings again? I honestly don't remember. Yes please, let's use debian11 in the URL somewhere. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: getting rid of "testing"
> "Ian" == Ian Jackson writes: Ian> Stepping back a bit: Ian> Can we have a comment from ftpmaster on their view of the rough Ian> consensus here? I think a Last Call (time-bounded) would be Ian> good. (I really liked the approach Sam took with the dh Ian> discussion.) Seconded. Personally, speaking very much as an individual, I'd appreciate it if Ansgar were to make a consensus call here as the developer who started the discussion. --Sam
Re: getting rid of "testing"
On Thu, 27 Jun 2019 at 12:04:39 +0100, Ian Jackson wrote: > [What is currently stable, etc.] is available via the ftpmaster API > service, and by reading symlinks > in archive mirrors. I think the idea of having this information in a > .deb too (ideally kept up to date in all in-support releases, > including LTS) is a good one. distro-info-data.deb has this information for Debian and Ubuntu, in a CSV file. It has convenience bindings for Perl, Python and CLI, and is also used by recent versions of Debian's implementation of lsb-release. It doesn't currently get an exemption from (old)stable releases' stability policies, but the data is in src:distro-info-data, separated from the convenience bindings in src:distro-info, presumably so that it could get updated more often if that was felt to be important. smcv
Re: getting rid of "testing"
Michael Stone writes ("Re: getting rid of "testing""):
> On Wed, Jun 26, 2019 at 01:29:44PM -0300, Antonio Terceiro wrote:
> >As a data point, having "stable" and "testing" stay around is very
> >useful for CI purposes. For example on ci.debian.net all our setup uses
> >"stable" and "testing" instead of the release codenames, and it's useful
> >to have a system that does not need manual intervention when the meaning
> >of "stable" and "testing" changes.
>
> Ideally, a mapping of what is currently "stable" or "testing" or at
> other levels of support would be easy to determine programatically, so
> you could avoid manual intervention for those cases and make it easy to
> support other cases without having to either manually configure things
> *or* make a bunch of new ugly symlinks.
It is available via the ftpmaster API service, and by reading symlinks
in archive mirrors. I think the idea of having this information in a
.deb too (ideally kept up to date in all in-support releases,
including LTS) is a good one.
But that doesn't mean we shouldn't have version aliases.
Stepping back a bit:
Can we have a comment from ftpmaster on their view of the rough
consensus here? I think a Last Call (time-bounded) would be good.
(I really liked the approach Sam took with the dh discussion.)
When an ftpmaster decision has been made, we can close this thread
(which is starting to become a distraction).
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:15:49PM +0200, Alf Gaida wrote: Only a last thought: Didn't we have really important problems to solve? It might be only me, but i see the discussion as a minor variation of bike shedding. It may not be important to you, but it's evidently important to some people. I think bike shedding is a mischaracterisation of this discussion, because a) the problems that occur with the current arrangement have been clearly identified and are substantive, not trivial; b) the ratio of proposed alternatives to participants is not near 1:1. To sum it up: Some people like codenames, some not, same for numbers - the real question is: Does it really matters? This is a bad summary. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:07:23PM +, Andrew M.A. Cater wrote: Think again about why we have release names at all: Debian 1.0 never happened because somebody packaged a pre-release semi-broken version as Debian 1.0 on their CDs. At that point, Debian chose to also use codenames to refer to releases in progress. Raspbian have released "Buster" before we have. Codenames have not prevented this happening. For me, I like the idea of being able to use the codename as soon as it is usable - that means that the distro tracks from unstable -> testing -> stable without a change. This would work with version numbers instead of code names. Pinning to stable is a silly idea in /etc/apt/sources.list - as soon as a release state changes - so if I have "stable" as my referent with 9.9, there'll be chaos as Buster is released and a forced upgrade This can be prevented by pinning to a version-number-name as well as code names. Having stable, testing, unstable as labels does mean I have to explain more to colleagues but it also means that I can confidently tell my colleagues: "Use the latest released stable Debian version if you want longer term support" They still have to resolve what that means, right? You don't want them putting "stable" in pinning etc. for the reason you list above. So, they still have to map stable → codename, and could just as easily map stable → version number. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 04:50:39PM +0200, Andreas Tille wrote: Hi, On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: I know +1 postings are not really welcome. I've been looking for an excuse to write slightly more than "+1" (to Simon or Phil's messages, in particular), but "+1" is substantively my main feeling However, in this case: I never really understood why we need these codenames. IMHO some marketing thingy which I tend to ignore. I fully agree with Phil that these can lead to confusion and the usage should be restricted to not so important use case. One thing that the code names give is colour. When I was (briefly) involved in debian-desktop stuff, the artists and suchlike enjoyed working on themes that riffed on the codename. I remember in particular being excited about what could be done with "Etch" and the swirl logo. So I would like to see the code names continue to exist, but I agree entirely that they should be reduced in importance and we should lead with the version number. We could consider bumping the version number up to match the current C.E. year, abbreviated (e.g. "19") in common with what Ubuntu do, if we wanted to increase the remember-or-computability of the current version. I do like how easy it is to look at an existing release number and be able to establish how old it is (aah, 18.04, was released in April 2018) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, 2019-06-26 at 14:54 -0400, Michael Stone wrote: > Wouldn't it be nicer to have a reliable and simple source of version > ordering rather than relying on ugly names and symlinks? As a bonus, it > would be useful for a lot more things and for more than n-2 > calculations. That doesn't seem useful for my use-case since it would mean I have to update my chdist sources.list after every release, while using the suite names doesn't require work after every release. I don't think this has to be a one-or-the-other scenario where the different use-case factions try to kill off the features used by other factions rather than living in harmony through co-existing features. I think we can support all use-cases quite simply by: Keeping the existing suite names and adding new *-backports ones. Adding a way for folks to use version-based sources.list entries. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: getting rid of "testing"
> "Michael" == Michael Stone writes: Michael> On Wed, Jun 26, 2019 at 09:01:03AM +0800, Paul Wise wrote: >> I also should mention that I use all of stable stable-updates >> proposed-updates and the equivalents for old/oldold. I have them >> in the apt sources of a chdist so I can easily look up old >> versions, do apt-file searches on old versions, look up non-amd64 >> architecture info etc. Michael> Wouldn't it be nicer to have a reliable and simple source Michael> of version ordering rather than relying on ugly names and Michael> symlinks? As a bonus, it would be useful for a lot more Michael> things and for more than n-2 calculations. No, not really. People have enumerated a couple of cases where stable et al are the right cases. You want a sources.list entry that changes what it points to over time. The examples seem to fall into the category of things that intentionally rebuild their environment or things that are providing data based on what is currently Debian's stable/whatever distribution. These are valid use cases and they really do seem to be served better by stable and friends than by things that require the sources.list to change. Testing and unstable have clear demonstrated utility in a sources.list entry as well. --Sam
Re: getting rid of "testing"
On 26/06/2019 19:58, Michael Stone wrote: > On Wed, Jun 26, 2019 at 02:23:40PM -0500, Andrej Shadura wrote: >> On Wed, 26 Jun 2019 at 14:13, Michael Stone wrote: >>> >>> On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: >>> >I'm perfectly capable of typing slink when I meant stretch. The coming >>> >era of b* releases is going to be a right pain for me. >>> >>> FWIW, I still confuse bo and buzz. :) >> >> How about buzz and buzzter? :) > > They're all terrible. I routinely say squeeze when I mean stretch, and > then when I log in somewhere and see stretch I wonder why it's running > such an old release. :( > Think again about why we have release names at all: Debian 1.0 never happened because somebody packaged a pre-release semi-broken version as Debian 1.0 on their CDs. At that point, Debian chose to also use codenames to refer to releases in progress. For me, I like the idea of being able to use the codename as soon as it is usable - that means that the distro tracks from unstable -> testing -> stable without a change. Pinning to stable is a silly idea in /etc/apt/sources.list - as soon as a release state changes - so if I have "stable" as my referent with 9.9, there'll be chaos as Buster is released and a forced upgrade Having stable, testing, unstable as labels does mean I have to explain more to colleagues but it also means that I can confidently tell my colleagues: "Use the latest released stable Debian version if you want longer term support" That, and the fact that security updates refuse to apply with an error message if you're too far behind / the clock is wrong are both fantastic features IMHO. All the very best, as ever, Andy C.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 02:23:40PM -0500, Andrej Shadura wrote: On Wed, 26 Jun 2019 at 14:13, Michael Stone wrote: On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: >I'm perfectly capable of typing slink when I meant stretch. The coming >era of b* releases is going to be a right pain for me. FWIW, I still confuse bo and buzz. :) How about buzz and buzzter? :) They're all terrible. I routinely say squeeze when I mean stretch, and then when I log in somewhere and see stretch I wonder why it's running such an old release. :(
Re: getting rid of "testing"
Only a last thought: Didn't we have really important problems to solve? It might be only me, but i see the discussion as a minor variation of bike shedding. To sum it up: Some people like codenames, some not, same for numbers - the real question is: Does it really matters? Over and out Alf
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: I'm perfectly capable of typing slink when I meant stretch. The coming era of b* releases is going to be a right pain for me. FWIW, I still confuse bo and buzz. :)
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 01:29:44PM -0300, Antonio Terceiro wrote: As a data point, having "stable" and "testing" stay around is very useful for CI purposes. For example on ci.debian.net all our setup uses "stable" and "testing" instead of the release codenames, and it's useful to have a system that does not need manual intervention when the meaning of "stable" and "testing" changes. Ideally, a mapping of what is currently "stable" or "testing" or at other levels of support would be easy to determine programatically, so you could avoid manual intervention for those cases and make it easy to support other cases without having to either manually configure things *or* make a bunch of new ugly symlinks.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 04:13:00PM +0100, Ian Jackson wrote:
Andreas Tille writes ("Re: getting rid of "testing""):
I never really understood why we need these codenames.
Simon McVittie wrote:
| Back when the release team decided on a per-release basis whether
| this was a "major" or "minor" release, we had the excuse that we had
| to use a codename for testing because we didn't know whether etch
| would be released as Debian 3.2 or Debian 4.0
I was around at the time and I have a vague recollection which roughly
matches Simon's.
Not just that: after the faux-release debacle there was a push to avoid
numbers in case someone polluted one. We're much less dependent on CD
vendors these days, of course.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:01:03AM +0800, Paul Wise wrote: I also should mention that I use all of stable stable-updates proposed-updates and the equivalents for old/oldold. I have them in the apt sources of a chdist so I can easily look up old versions, do apt-file searches on old versions, look up non-amd64 architecture info etc. Wouldn't it be nicer to have a reliable and simple source of version ordering rather than relying on ugly names and symlinks? As a bonus, it would be useful for a lot more things and for more than n-2 calculations.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
As a data point, having "stable" and "testing" stay around is very
useful for CI purposes. For example on ci.debian.net all our setup uses
"stable" and "testing" instead of the release codenames, and it's useful
to have a system that does not need manual intervention when the meaning
of "stable" and "testing" changes.
With that said, I think that for regular user systems, having suites
called debian11 and the like is a great improvement.
signature.asc
Description: PGP signature
Re: getting rid of "testing"
Andreas Tille writes ("Re: getting rid of "testing""):
> I never really understood why we need these codenames.
Simon McVittie wrote:
| Back when the release team decided on a per-release basis whether
| this was a "major" or "minor" release, we had the excuse that we had
| to use a codename for testing because we didn't know whether etch
| would be released as Debian 3.2 or Debian 4.0
I was around at the time and I have a vague recollection which roughly
matches Simon's. This reason no longer applies, of course.
I regularly make mistakes about the sort order of these codenames.
I agree with the rest of Andreas's message.
> Please leave testing as a name
As I said, I see no reason why [[old]old]stable and unstable need to
be abolished as names. They will still be useful in conversation,
even if they were never very useful in apt soruces.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: getting rid of "testing"
Hi, On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: > The version numbers are also showing up on login and desktop backgrounds > so I'd guess the bulk of users know exactly which number they're up to, > but a pretty vague about which codename goes with that. > > Oh, and for me that also applies to speech -- if you say 10 to me, > there's no way I'll later remember 9, but if you say buster, I'm quite > likely to remember "two sylables, begins with B". > > Can we not just have both? I know +1 postings are not really welcome. However, in this case: I never really understood why we need these codenames. IMHO some marketing thingy which I tend to ignore. I fully agree with Phil that these can lead to confusion and the usage should be restricted to not so important use case. Please leave testing as a name as is - I'm using it most of the time on development machines and it serves a really good purpose. Those who do not like it can easily ignore it. Kind regards Andreas. -- http://fam-tille.de
Re: getting rid of "testing"
Michael Stone writes: > On Tue, Jun 25, 2019 at 08:07:51PM +0800, Paul Wise wrote: >>On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: >>> Having "stable" in sources.list is broken, because one day stuff goes >>> from working to not working, which requires manual intervention, at >>> which point someone could have just changed the name. Having codenames >>> in sources.list is broken, because even people who have been developers >>> for two decades can't remember which release is which without looking it >>> up. (Which is harder than it should be; maybe we should have had >>> /etc/debian-releasenames or somesuch from the beginning. lsb_release -a >>> is helpful when available but doesn't have context, and many users don't >>> know it exists.) >> >>Personally, I can remember the names and their order much better than >>which version goes with which codename or suite :) > > Well, every problem domain has its rainman :) For the rest of us, > there's google. Personally, I use wikipedia's page about debian revisions, and it's not that uncommon an event for me to need to look that up just to make sure I've not made a stupid typo. I like the idea of adding the list of releases somewhere (probably under /usr/share/doc though, and including dates for start and end of support etc. perhaps) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: getting rid of "testing"
Adam Borowski writes:
> On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
>> Hi,
>>
>> what do people think about getting rid of current suite names ("stable",
>> "testing", "unstable") for most purposes? We already recommend using
>> codenames instead as those don't change their meaning when a new release
>> happens.
>
> And for this exact reason so many people want "testing" not "buster".
>
> This way they get 5-days-newest versions of everything, without having to
> suffer broken uploads, broken dependencies, etc.
>
> Using "buster" would mean that at some moment their updates suddenly stop,
> and they have to manually migrate to the next version.
>
>> Related to that I would like to be able to write something like
>>
>> deb http://deb.debian.org/debian debian11 main
>> deb http://security.debian.org/debian-security debian11-security main
>>
>> in sources.list as codenames confuse people.
>
> Hell no! Even though I'm among most active DDs around, I just had to look
> up whether "debian11" means Buster or Bullseye.
>
> It's same eg. for processor names: "Skylake" means Skylake, which is used
> within 6 or 7 different numbering schemes. Even people who care what
> processor that is will so often need to look up versioning numbers -- as the
> public names are about marketing segments and so on, not about how a
> processor behaves.
>
> A code name is also so much easier to talk about, especially in speech -- a
> codename is one or two fairly unique syllables, while a number is longer,
> and it's usually surrounded by other numeric values within other semantic
> domains.
These things are clearly a matter of taste.
For me, the numbers would be _much_ more useful.
I'm perfectly capable of typing slink when I meant stretch. The coming
era of b* releases is going to be a right pain for me.
I would certainly not end up typing 2.1 when I meant 9 though, and if
somehow I did, I would be able to notice the mistake instantly, whereas
my dyslexia will cheerfully hide the wrong name for long enough to allow
quite a lot of hair pulling.
The version numbers are also showing up on login and desktop backgrounds
so I'd guess the bulk of users know exactly which number they're up to,
but a pretty vague about which codename goes with that.
Oh, and for me that also applies to speech -- if you say 10 to me,
there's no way I'll later remember 9, but if you say buster, I'm quite
likely to remember "two sylables, begins with B".
Can we not just have both?
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 4:39 PM Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
>
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend using
> > codenames instead as those don't change their meaning when a new release
> > happens.
>
> I use these (testing, etc) so getting rid of them would be annoying.
I also should mention that I use all of stable stable-updates
proposed-updates and the equivalents for old/oldold. I have them in
the apt sources of a chdist so I can easily look up old versions, do
apt-file searches on old versions, look up non-amd64 architecture info
etc.
I would also love to have stable-backports be a thing, so I don't have
to change my chdist apt sources from codename1-backports to
codename2-backports every time a release happens.
I use chdist for when I'm offline or when I want to see what is on the
mirrors, since rmadison shows the ftp-master view.
PS: apt-venv is another option for this use-case.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On 6/25/19 8:08 AM, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
>
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
>
> Ansgar
Are we going to have rc-buggy as an alias to Experimental? :)
Cheers,
Thomas Goirand (zigo)
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 09:43:02PM +0500, Andrey Rahmatullin wrote: On Tue, Jun 25, 2019 at 12:40:01PM -0400, Michael Stone wrote: > and so on - i take the older releases only as reference. I just do something like look at https://packages.debian.org/ssh Or, if I'm really curious about versions, then something like http://snapshot.debian.org/package/openssh/ rmadison(1) and https://tracker.debian.org/ are probably better. Those are also good options for additional use cases. :) At any rate, putting every release ever into sources.list is generally not the best available mechanism.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 12:40:01PM -0400, Michael Stone wrote: > > and so on - i take the older releases only as reference. > > I just do something like look at https://packages.debian.org/ssh > Or, if I'm really curious about versions, then something like > http://snapshot.debian.org/package/openssh/ rmadison(1) and https://tracker.debian.org/ are probably better. -- WBR, wRAR signature.asc Description: PGP signature
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:28:13PM +0200, Alf Gaida wrote: On 25.06.19 17:48, Michael Stone wrote: oldoldstable has the value of demonstrating some of what's wrong with the current system Can you please explain, i don't get it - maybe i to new at this. For me file like /etc/apt/sources.lists.d/debian.list: wow, that slows down every package operation on the system as you download or search 6+ versions of everything. and so on - i take the older releases only as reference. I just do something like look at https://packages.debian.org/ssh Or, if I'm really curious about versions, then something like http://snapshot.debian.org/package/openssh/ If you've got some kind of weird requirement to have everything local, I'd still rather see something like "debian8" in the output than "oldoldstable"--a name that changes over time and is therefore relative to both a reference system and a specific system at the time that entry was created. If I want a specific version of a package, it will only be in "oldoldstable" up until "oldoldstable" is something entirely different. I'm still not understanding a use case where that's an advantage.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:28:13PM +0200, Alf Gaida wrote: > > oldoldstable has the value of demonstrating some of what's wrong with > > the current system > > Can you please explain, i don't get it That name is stupid. -- WBR, wRAR signature.asc Description: PGP signature
Re: getting rid of "testing"
On 25.06.19 17:48, Michael Stone wrote: oldoldstable has the value of demonstrating some of what's wrong with the current system Can you please explain, i don't get it - maybe i to new at this. For me file like /etc/apt/sources.lists.d/debian.list: deb http://ftp.debian.org/debian/ oldoldstable main contrib non-free deb-src http://ftp.debian.org/debian/ oldoldstable main contrib non-free deb http://ftp.debian.org/debian/ oldstable main contrib non-free deb-src http://ftp.debian.org/debian/ oldstable main contrib non-free deb http://ftp.debian.org/debian/ stable main contrib non-free deb-src http://ftp.debian.org/debian/ stable main contrib non-free deb http://ftp.debian.org/debian/ testing main contrib non-free deb-src http://ftp.debian.org/debian/ testing main contrib non-free deb http://ftp.debian.org/debian/ unstable main contrib non-free deb-src http://ftp.debian.org/debian/ unstable main contrib non-free deb http://ftp.debian.org/debian/ experimental main contrib non-free deb-src http://ftp.debian.org/debian/ experimental main contrib non-free deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free deb-src http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main contrib non-free deb http://ftp.debian.org/debian/ stretch-backports main contrib non-free is perfectly fine. So it is possible for me -- strictly running sid with buildd on _my_ production system -- doing things like: % apt policy nano nano: Installiert: 3.2-3 Installationskandidat: 3.2-3 Versionstabelle: 4.1-1 1 1 http://ftp.debian.org/debian experimental/main amd64 Packages *** 3.2-3 500 500 http://ftp.debian.org/debian testing/main amd64 Packages 500 http://ftp.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status 2.7.4-1 500 500 http://ftp.debian.org/debian stable/main amd64 Packages 2.2.6-3 500 500 http://ftp.debian.org/debian oldstable/main amd64 Packages and so on - i take the older releases only as reference. So for me there is a use case, i'm not interested in older versions as old or oldoldstable - and i will never change this file without reason. Cheers Alf
Re: getting rid of "testing"
Am Dienstag, den 25.06.2019, 11:48 -0400 schrieb Michael Stone: > On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: > > Only a few remarks as former simple user and now maintainer: > > * Please don't mix things: release names has a value, distribution > > names like oldoldstable, oldstable, stable, testing, unstable has > > their value too > > oldoldstable has the value of demonstrating some of what's wrong > with > the current system Then running wheezy will be fine once buster is released, because oldoldstable will point to jessie and wheezy won't have a release name any more? Some admins ask: "How many reboots until the next Debian release?" Others ask: "How many Debian releases until the next reboot?" I can images systems that are getting bought, setup, and after several years shutdown and retired without rebooting or dist-upgrading them. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 06:06:55PM +0200, Benjamin Drung wrote: Am Dienstag, den 25.06.2019, 11:48 -0400 schrieb Michael Stone: On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: > Only a few remarks as former simple user and now maintainer: > * Please don't mix things: release names has a value, distribution > names like oldoldstable, oldstable, stable, testing, unstable has > their value too oldoldstable has the value of demonstrating some of what's wrong with the current system Then running wheezy will be fine once buster is released, because oldoldstable will point to jessie and wheezy won't have a release name any more? Some admins ask: "How many reboots until the next Debian release?" Others ask: "How many Debian releases until the next reboot?" I can images systems that are getting bought, setup, and after several years shutdown and retired without rebooting or dist-upgrading them. I have no idea what you're trying to say, sorry.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 05:01:48PM +0200, Alf Gaida wrote: Only a few remarks as former simple user and now maintainer: * Please don't mix things: release names has a value, distribution names like oldoldstable, oldstable, stable, testing, unstable has their value too oldoldstable has the value of demonstrating some of what's wrong with the current system
Re: getting rid of "testing"
Only a few remarks as former simple user and now maintainer: * Please don't mix things: release names has a value, distribution names like oldoldstable, oldstable, stable, testing, unstable has their value too * the value is that they never change - they are convenient. Especially if one use unstable most of the time, please think of such things like `apt policy $foo` - it is highly unlikely that a sid user want to use old stuff, but will ask from time to time about versions ... * using the release names is convenient to set up systems before the release is done - i can set up a "buster" system now and have to change nothing when it become stable. The other way around is not a good way to go. At all - using distributions like "testing" or "unstable" should mean that the users/admins in charge can handle it - if not they should learn it or never ever do such things again. Might sound stubborn, but hey - i learned it this way. As a user of a rock stable "Sid" system i see no big problems for ten years now - ok, maybe to resist this: Hmm, what will happend if i will hit now ... Cheers Alf
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 02:38:43PM +0200, Bastian Blank wrote: On Tue, Jun 25, 2019 at 08:03:49AM -0400, Michael Stone wrote: Having "stable" in sources.list is broken, because one day stuff goes from working to not working, which requires manual intervention, at which point someone could have just changed the name. Once I had unattended-upgrades do the upgrade to the new stable for me over night on quite a few systems, almost everything still worked. "almost" covers quite a lot of territory, and is the reason it's best not to have the upgrade happen accidentally.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:03:49AM -0400, Michael Stone wrote: > Having "stable" in sources.list is broken, because one day stuff goes from > working to not working, which requires manual intervention, at which point > someone could have just changed the name. Once I had unattended-upgrades do the upgrade to the new stable for me over night on quite a few systems, almost everything still worked. Regards, Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:07:51PM +0800, Paul Wise wrote: On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: Having "stable" in sources.list is broken, because one day stuff goes from working to not working, which requires manual intervention, at which point someone could have just changed the name. Having codenames in sources.list is broken, because even people who have been developers for two decades can't remember which release is which without looking it up. (Which is harder than it should be; maybe we should have had /etc/debian-releasenames or somesuch from the beginning. lsb_release -a is helpful when available but doesn't have context, and many users don't know it exists.) Personally, I can remember the names and their order much better than which version goes with which codename or suite :) Well, every problem domain has its rainman :) For the rest of us, there's google.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: > Having "stable" in sources.list is broken, because one day stuff goes > from working to not working, which requires manual intervention, at > which point someone could have just changed the name. Having codenames > in sources.list is broken, because even people who have been developers > for two decades can't remember which release is which without looking it > up. (Which is harder than it should be; maybe we should have had > /etc/debian-releasenames or somesuch from the beginning. lsb_release -a > is helpful when available but doesn't have context, and many users don't > know it exists.) Personally, I can remember the names and their order much better than which version goes with which codename or suite :) -- bye, pabs https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 11:09:06AM +0100, Ian Jackson wrote:
~Ansgar writes ("getting rid of "testing""):
Related to that I would like to be able to write something like
deb http://deb.debian.org/debian debian11 main
deb http://security.debian.org/debian-security debian11-security main
in sources.list as codenames confuse people.
Yes, please, absolutely. And this should be the default.
+1
Having "stable" in sources.list is broken, because one day stuff goes
from working to not working, which requires manual intervention, at
which point someone could have just changed the name. Having codenames
in sources.list is broken, because even people who have been developers
for two decades can't remember which release is which without looking it
up. (Which is harder than it should be; maybe we should have had
/etc/debian-releasenames or somesuch from the beginning. lsb_release -a
is helpful when available but doesn't have context, and many users don't
know it exists.)
Re: getting rid of "testing"
On Tue, 2019-06-25 at 16:39 +0800, Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend using
> > codenames instead as those don't change their meaning when a new release
> > happens.
>
> I use these (testing, etc) so getting rid of them would be annoying.
The "stable" suite names are more annoying than
unstable/testing/experimental as they require updates to suites at
release time that are not related to the release. That shouldn't be
necessary.
For "testing", "unstable" one could probably introduce some `Alias`
field in Release, but I also like minimalist solutions (which already
seem to work well for Ubuntu).
> > Related to that I would like to be able to write something like
> >
> > deb http://deb.debian.org/debian debian11 main
>
> Already kind of possible:
>
> deb http://deb.debian.org/debian Debian9.9 main
Yes, but it gives warnings for issues that I believe should be an error
instead. (And currently a good reason for TLS to talk to mirros so a
MitM that is not a mirror operator cannot give you oldstable when you
want to use unstable.)
debootstrap gives an error for this:
+---
| $ /sbin/debootstrap --print-debs Debian9.9 . http://ftp.de.debian.org/debian
unstable
| [...]
| E: Asked to install suite Debian9.9, but got stable (codename: stretch) from
mirror
+---
As Adam already pointed out having the point release in there also
makes "Debian9.9" rather unhelpful.
> > Ubuntu already has no suite names, only codenames, but having to map
> > "Ubuntu 18.04" to "bionic" instead of just writing the version in
> > sources.list is annoying (I always have to look up the codename to be
> > sure as I don't use Ubuntu that much).
>
> They do have the 'devel' suite, but it is not a proper one:
>
> https://bugs.launchpad.net/ubuntu/+bug/1821272
That is what Debian9.9 (and similar) are currently as well.
Ansgar
Re: getting rid of "testing"
Ian Jackson [2019-06-25 11:09:06+01:00] wrote:
> ~Ansgar writes ("getting rid of "testing""):
>> deb http://deb.debian.org/debian debian11 main
>> deb http://security.debian.org/debian-security debian11-security main
> Yes, please, absolutely. And this should be the default.
> The syntax "debian11" is precisely right. Please don't add a hyphen
> to it, as hyphens are already used for separating things like
> -security.
> For now, the `debian11' can be an alias.
As a mere user I'd say this is the best approach: add debian10, debian
11 etc. alias or perhaps later make it the proper name.
My first Debian was Woody. I remember that Sarge was after that, then
Etch or Lenny (I think), but it all started to blur at that time. Now I
know that I'm using Debian 9 but don't remember its name. I don't
remember what was the name of the previous version.
I think it's best to use version numbers for communication with users
and to configure Debian (like sources.list).
Anyway, thank you for this excellent operating system.
--
/// Teemu Likonen //
// PGP: 4E1055DC84E9DFF613D78557719D69D324539450 ///
signature.asc
Description: PGP signature
Re: getting rid of "testing"
~Ansgar writes ("getting rid of "testing""):
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
Others have pointed out that "testing" has a specific value. Also,
these suite aliases have a documentary value. It can be helpful to
say things like "when this is languishing in oldstable ...".
So I would prefer to keep them.
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
Yes, please, absolutely. And this should be the default.
I know the codenames thing is fun but it is seriously inconvenient
when talking to anyone who is not completely steeped in Debian stuff.
Even Debian people sometimes make slips - and I'm sure they are more
common because we're having to constantly do these kind of codename
lookups.
I agree entirely with Simon.
The syntax "debian11" is precisely right. Please don't add a hyphen
to it, as hyphens are already used for separating things like
-security.
I don't think I have any software which would go wrong if there were
an extra hyphen but I would be amazed if there weren't a ton of ad-hoc
scripts out there that would be fine with the transition from
`bookwork' to `debian11' but would Go Wrong with `debian-11'.
For now, the `debian11' can be an alias. At some future point this
should become the canonical suite name, replacing the codename. But I
think this should not be done retrospectively to old suites, because
there is software outside the archive that wants to name things by a
single canonical name, and changing that name for an existing suite
will cause trouble.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
And for this exact reason so many people want "testing" not "buster".
This way they get 5-days-newest versions of everything, without having to
suffer broken uploads, broken dependencies, etc.
Using "buster" would mean that at some moment their updates suddenly stop,
and they have to manually migrate to the next version.
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
Hell no! Even though I'm among most active DDs around, I just had to look
up whether "debian11" means Buster or Bullseye.
It's same eg. for processor names: "Skylake" means Skylake, which is used
within 6 or 7 different numbering schemes. Even people who care what
processor that is will so often need to look up versioning numbers -- as the
public names are about marketing segments and so on, not about how a
processor behaves.
A code name is also so much easier to talk about, especially in speech -- a
codename is one or two fairly unique syllables, while a number is longer,
and it's usually surrounded by other numeric values within other semantic
domains.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄
Re: getting rid of "testing"
On 2019-06-25 09:39, Paul Wise wrote: On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote: Related to that I would like to be able to write something like deb http://deb.debian.org/debian debian11 main Already kind of possible: deb http://deb.debian.org/debian Debian9.9 main With the caveat that as soon as 9.10 happens, the 9.9 symlink will cease existing. Regards, Adam
Re: getting rid of "testing"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2019-06-25 09:46, Bastian Blank wrote: > On related notes: For Azure we currently plan (yeah, still not > finished as MS does not provide input, be we still need to change > it): - debian-10 - debian-11 - debian-sid And docker hub have some similar things with the version tags. stable, 9 and stretch are the same target. And for those not familiar with the docker targets: $ docker run debian:stable cat /etc/debian_version More info https://hub.docker.com/_/debian/ I can see good reasons for having the classic names still (testing, unstable and so on) - the great benefit would be to have the version numbers available as well. Different audiences in target I think. - -- brother http://sis.bthstudent.se -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAl0R4Z0ACgkQOIRDexPY /4tOLA/9EYugAyJWehITg2mpOS0oE75nV1e/UAO1SczBiWNC+io9ostWaANaR4xT eEMLnHfZCtVmiJYlCvepcK6EnSD42vx5nrVbFTUZR82AYR2QyL5yKbYoYUNzC3Px Nj4g2KFzAscr7KXJ6arXdP9GqJmIJR7vao3T0z0TXVcL/gpfyN3kYVt82f99Zpzp 0qAewKZLq5hmhBRSnYHioqWes6WvdybMHzsG9uwVLzuVCTJQQ5BcqXrgBuXJPQG5 5/xhbIxnFpbN74XoiGIydvrPmF2/CcYGGMd8lVS0dwpQbBeTe6wqXOx+edqj3Ioo eSOz8IoQeGVae0THUDSH+Ezp1UMblK47oB/erzyvy3FEufvsyuLxjdz/KuLwL2/H 0uzxhRN5jOlGg+xzR1WeOcxyjrQEKv5sVcuNla64QNuzDopnJqd2gEnxAGiRMKcK N/ftpXRo7WJrROBNu51+hSHxGuACJVajsrE1qQqvCR65ycoRWGj/twABD+HTJ4hm S8392KXpVRqQmFMfZs+u7JPiCAxzzcOmgDolhYZxljNoBRsAosRJfEQvH/tGLpU3 lAbHkzhMjeZ2SmXfFPy11cHbQQVLhBw3C7QZaZaLbxUwVqEMaqQyi8KLlj2DNsP/ jzW2NOXdHogUXL6u6ZzgbDlHAR++lhomKVApYcPaAp8P/b/5J7k= =vGqi -END PGP SIGNATURE-
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
I use these (testing, etc) so getting rid of them would be annoying.
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
Already kind of possible:
deb http://deb.debian.org/debian Debian9.9 main
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
They do have the 'devel' suite, but it is not a proper one:
https://bugs.launchpad.net/ubuntu/+bug/1821272
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On Tue, 25 Jun 2019 at 13:11:09 +0500, Andrey Rahmatullin wrote: > On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > Can you please elaborate on the "confuse people"? > > I guess only (most?) Debian contributors and hardcore Debian users > remember the order of the codenames and their mappings to current > stable/oldstable/testing and to numeric versions. Yes, exactly. This is a frequent request from those of my colleagues who mostly use other distributions, but occasionally have to interact with Debian, and can't remember whether stretch is older or newer than jessie. This is going to be particularly bad after the buster release, when buster and bullseye are current, and even worse after the bullseye release, when buster, bullseye and bookworm will all be relevant. Ubuntu is easier in some ways (because the alphabetical codenames go in a logical sequence) but harder in others (because the distinction between LTS and non-LTS isn't obvious from the codenames). Back when the release team decided on a per-release basis whether this was a "major" or "minor" release, we had the excuse that we had to use a codename for testing because we didn't know whether etch would be released as Debian 3.2 or Debian 4.0; but now that we've decided that every release is a major version, we can predict well in advance that Debian 10 will be followed by Debian 11 and Debian 12, so there doesn't seem a whole lot of point in obfuscating it. With more emphasis on the version numbers, my non-Debian colleagues would still have to learn (or look up) which release is the current stable, but given that information they would immediately also know which release was the previous one (subtract 1) and which release is under development (add 1). Referring to testing in speech/writing as something like Debian 10 alphas/betas/pre-releases (to express that it *will be* Debian 10, but it isn't really Debian 10 *yet*) might make more sense to non-Debian people, and might have the desirable side-effect of having more Debian contributors get the message that it's a means to an end (making the next release happen) rather than a product in its own right. In machine-readable contexts like sources.list it's probably best to use something like debian10 (or deb10, as in stable updates' version strings, or just 10) so that it doesn't have to change on release day. smcv
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > Related to that I would like to be able to write something like > > deb http://deb.debian.org/debian debian11 main > > deb http://security.debian.org/debian-security debian11-security main > > in sources.list as codenames confuse people. > > Can you please elaborate on the "confuse people"? I guess only (most?) Debian contributors and hardcore Debian users remember the order of the codenames and their mappings to current stable/oldstable/testing and to numeric versions. -- WBR, wRAR signature.asc Description: PGP signature
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
Even if we stop advertising them, could we keep them as a generic set of
aliases?[1]
> Related to that I would like to be able to write something like
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
> in sources.list as codenames confuse people.
Can you please elaborate on the "confuse people"?
I think adding such names would be a good idea, as long as we stay on
simple versions. Or we use "debian-11", then it does not look that ugly
to do "debian-23.42".[2]
What would you do about sid? It got no version.
On related notes:
For Azure we currently plan (yeah, still not finished as MS does not
provide input, be we still need to change it):
- debian-10
- debian-11
- debian-sid
Regards,
Bastian
[1]: I think apt would need to learn about aliases.[2] As would dak, to
maintain them automatically.
[2]: Maybe we could even use them for bullseye/updates ->
bullseye-security and keep the former as alias without apt complaining
about it.
--
There's coffee in that nebula!
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"
Re: getting rid of "testing"
On Ma, 25 iun 19, 08:08:22, Ansgar wrote:
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
AFAIK "unstable" is always symlinked to "sid", so it wouldn't make a
difference and also manages expectations ;)
"stable", besides significantly changing it's meaning at release may
also be actively harmful if one dist-upgrades by mistake[1] with
'stable' in sources.list.
While dist-upgrades are significantly smoother the Release Notes still
have important items that must be taken care of before/during/after
dist-upgrade.
Depending on your intention using "testing" may or may not be what you
want to have in sources.list even through releases.
Users that dist-upgrade early or install the next release while it's
still in testing for $reasons (e.g. hardware support, newer software
that is not available in backports, etc.) should always use the codename
to avoid surprises at release (as per above for "stable).
Those who want to stick with "testing" no matter what I believe[2] are
actually looking for a rolling distribution so it would probably make
sense to rename "testing" to "rolling"[3][4].
[1] because 'apt-get upgrade' doesn't install new packages many users
have developed a habit to always run 'apt-get dist-upgrade', e.g. to
upgrade their kernel package (in case of ABI change).
Users are slowly migrating to 'apt upgrade', but running 'apt-get
dist-upgrade' on stable just to get security upgrades will not disappear
anytime soon.
[2] based on more than 10 years experience on debian-user.
[3] or remove the "testing" symlink/name and add the "bob" rolling
release that was proposed in
https://lists.debian.org/debian-devel/2011/06/msg00136.html
[4] or "roling" to emphasize that it's incomplete :p
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
Re: getting rid of "testing"
what do people think about getting rid of current suite names ("stable",
"testing", "unstable") for most purposes? We already recommend using
codenames instead as those don't change their meaning when a new release
happens.
Hi Ansgar,
Regarding suite names (stable, testing, and unstable), there are for
convenience if you rather just want to stick to
particular distribution. If suite names are removed, you have to update
sources.list whenever a new release is made
in order to keep up to date to your chosen suite. If you e.g. track buster
(which at the time of writing is in testing)
instead of testing, you are tracking buster until EOL.
PS: I'm not Debian User or Developer, so my opinion can be misleading.
Regards, Bagas
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
Are you supposed to change the code name manually if you want to stay on
testing after a release happens?
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
Yes please.
--
WBR, wRAR
signature.asc
Description: PGP signature
