Debian and code names
Debian typically uses code names to refer to its releases, starting with the Toy Story character names used (mostly) instead of numbers. The "Buster" release is due on July 6 and you will rarely hear it referred to as "Debian 10". There are some other code names used for repository (or suite) names in the Debian infrastructure; "stable", "testing", "unstable", "oldstable", and sometimes even "oldoldstable" are all used as part of the sources for the APT packaging tool. But code names of any sort are hard to keep track of; a discussion on the debian-devel mailing list looks at moving away from, at least, some of the repository code names.
The issue was raised by Ansgar
Burchardt, who wondered if it made sense to move away from the stable,
unstable, and
testing suite names in the sources.list
file used by APT. Those labels,
except for unstable, change the release they are pointing at when a new
release gets made. Currently stable points to "Jessie Stretch" (Debian 9),
while testing points to Buster. Soon, stable will point to Buster,
testing will point at "Bullseye", which will become Debian 11.
He asked about using the release code names directly, instead, so that
pointing a system at Stretch would continue to get packages from that
release. But he also thought it would be nice to completely route around
the code names, which "confuse people
". He suggested lines
that looked like the following in sources.list:
deb http://deb.debian.org/debian debian11 main
deb http://security.debian.org/debian-security debian11-security main
He noted that Ubuntu does not use suite names but the code-name problem
still rears its head: "[...] having to map 'Ubuntu 18.04' to 'bionic' instead of just writing the version in sources.list is annoying".
Andrei Popescu pointed
out some of the perils of using stable and testing around the time of a
release. Many users have (mostly incorrectly) trained themselves to do a
apt-get dist-upgrade instead of a regular
apt-get upgrade to pick up new package versions, but that can
go badly awry if stable has just changed. Those who stick with testing, he
said, are really looking for a rolling release, so perhaps testing should
be renamed to "rolling"—"or 'roling' to emphasize that it's
incomplete :p
".
The code names are particularly hard for those only tangentially connected
to Debian, Simon McVittie said.
He notes that there will be three releases with code names that start with
"B" before too long; after Buster and Bullseye comes Bookworm. Originally,
part of the reason for code names was because it was not clear whether the
next release would be considered a point release or not: "we didn't
know whether etch would be
released as Debian 3.2 or Debian 4.0
". Now each release
is a major version bump, so it would help outsiders to use those more:
But Adam Borowski is adamant that the code names are easier to work with. He complained that he had to look up whether Debian 11 was Buster or Bullseye, but others have the opposite problem. Going back in time is difficult as well, as Wouter Verhelst related:
But what were the orderings again? I honestly don't remember.
Philip Hands also has
trouble remembering code names, but he (and others) suggested:
"Can we not just have both?
" Certainly the testing suite name
is considered useful by many, so it will presumably remain in any plan that
might emerge. And Ian Jackson thinks
that the other suite names should stick around for reference purposes but
that using "debian11" in sources.list should be the default going
forward:
Michael Stone summed up the thinking of many in the thread with regard to names, rather than versions, in sources.list:
Several lamented that it was painful to actually do that lookup at times. Wikipedia has a good reference page, but something closer to home would be useful. McVittie pointed to the distro-info-data package, which has those mappings in a CSV file and provides bindings for various languages; it is used by the lsb-release package to report distribution version information. That helps, but the consensus still seems to be that providing a version-number-based system (in addition to the existing suite names) makes sense.
In fact, Jackson suggested
a call for rough consensus as was done by Debian project leader Sam Hartman
for the dh discussion in June. Hartman seconded that
call, suggesting that Burchardt do so "as the developer who started
the discussion
". So far, that has not occurred, however.
Perhaps inevitably, the idea of moving to year-based version numbers (or
"release identifiers
") was raised; Tomas Pospisek said
that the code names are getting confusing and that "sequential
release numbers are devoid of any semantics except for their
monotonically increasing character
". Year-based version numbers
is, of course, what
Ubuntu uses, but there is a big difference between the two: Ubuntu sets its
release date in advance, while Debian release dates are rather more fluid. The
pros and cons of that approach were discussed, with the idea of
alphabetically increasing code names thrown in for good measure, but few
beyond Pospisek seemed wildly enthused by the idea. As Paul Wise put
it:
That's where things stand at this point. In general, code names are most useful within a community, rather than as a marketing or other tool to communicate with outsiders. Even when those names follow a clear pattern (e.g. Ubuntu, Android) they still seem to confuse to some extent. Numbers have the advantage of predictability, though without some kind of real-world mapping (e.g. date-based) the advantage is somewhat limited. But defaulting to a world where sources.list does not point to "stable", which suddenly changes at release time, seems like a goal worth pursuing. Outsiders and insiders alike can perhaps agree on that part.
Posted Jul 3, 2019 17:16 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (3 responses)
This article inadvertently emphasizes its own point:
Currently stable points to "Jessie" (Debian 9)
Actually, Debian-9 is "Stretch". So yes, I think codenames should only be used within the developer community, and numbers for public consumption.
Posted Jul 3, 2019 17:52 UTC (Wed)
by jake (editor, #205)
[Link] (2 responses)
Ouch, that's embarrassing ... fixed with a strikethrough ...
jake Posted Jul 3, 2019 18:05 UTC (Wed)
by wazoox (subscriber, #69624)
[Link] (1 responses)
Posted Jul 5, 2019 15:06 UTC (Fri)
by joey (guest, #328)
[Link]
Posted Jul 3, 2019 18:05 UTC (Wed)
by cjwatson (subscriber, #7322)
[Link] (1 responses)
Posted Jul 3, 2019 18:06 UTC (Wed)
by cjwatson (subscriber, #7322)
[Link]
Posted Jul 3, 2019 18:34 UTC (Wed)
by david.a.wheeler (subscriber, #72896)
[Link] (2 responses)
Posted Jul 4, 2019 11:23 UTC (Thu)
by joib (subscriber, #8541)
[Link] (1 responses)
Your point about familiarity to outsiders is good, though. If I were Dictator of Debian, I would choose just the year of release. So Buster would be "Debian 2019". For point releases, "2019.1" etc. (to avoid problems with schedule slipping causing the name to change at the last minute, plan for a release in the beginning of the year)
Posted Jul 4, 2019 12:46 UTC (Thu)
by shane (subscriber, #3335)
[Link]
One minor tweak would be use something like "2019.update1" or the like, to make clear that it is not referring to a month number (I might be confused if I saw "2018.5" come out in 2020).
Posted Jul 3, 2019 18:51 UTC (Wed)
by ju3Ceemi (subscriber, #102464)
[Link] (12 responses)
It let us personalize the release, it gives it a special identity
The upcoming Debian release is not just an anonymous number, one amongst the others
Numbers as a version are meaningless, which means people must learn them stupidly
Also, I am pretty certain that Toy Story 4 is secretly founded by Debian, to get a new pool of codenames.
Posted Jul 3, 2019 22:19 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (3 responses)
Once upon a time we gave names to each computer - maybe using some theme like colors or composers or cartoon characters etc - just like we do for pets.
Are distributions pets (you seem to think so, I might even agree) or cattle??
Posted Jul 4, 2019 2:42 UTC (Thu)
by gdt (subscriber, #6284)
[Link]
"Pets v cattle" isn't a useful analogy for distributions. Why can't they be racehorses -- both individually cared for and yet with an eye to temporal matters. Or whales -- in that if you think you are controlling the whale, well I've got some news. Or maybe even imaginary creatures from a Pixar movie :-)
Posted Jul 12, 2019 8:46 UTC (Fri)
by MiCRoPhoBIC (guest, #47807)
[Link] (1 responses)
Posted Jul 16, 2019 22:46 UTC (Tue)
by nix (subscriber, #2304)
[Link]
It does feel like something has been lost. Maybe we could get it some of it back, but I'm not sure how. (That world did have notable downsides, too: the bugger over there with a madly bloated Emacs pushing the machine deep into swap was too often, uh, me...)
Posted Jul 8, 2019 0:01 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Not inherently. And that's the problem. It's the same issue I have with macOS releases. Everyone there uses code names and I can't keep them straight. I can at least order "cats before rock formations" but that doesn't help other than that divide. At least Ubuntu is referred to by its release number in casual conversation so I at least have an idea of how old it is. All I know of Debian releases off-hand is that "jessie" is "recent" and "buster" is "newer" (though give it 6 months and I'll forget how "old" each is too for comparisons with other distros). Other than that, the names are just noise to me and I may as well just do a shuffle on them to try and order them. I'm a Fedora user where the name was dropped years ago completely and otherwise seemed to mainly be inspiration for distro art.
Posted Jul 8, 2019 18:40 UTC (Mon)
by Jandar (subscriber, #85683)
[Link] (6 responses)
Really? What kind of meaning is contained within "squeeze" or "jessie"? Codenames of Ubuntu or Mint with ascending first letters have a meaning, randomly chosen ones of a special set have no further meaning beyond being from this set (e.g. names from certain Pixar films).
I had for many years Debian as my desktop distro and still as my server distro but only during updating I remember the nonsensical codenames.
Please envision streets without numbers. Every street has codenames for the houses. Address: Jane Doe, Main Street / Diseased Merry Screwdriver. I assume you would have no problem finding the way to Jane Doe, because "Codename do have meanings".
Posted Jul 8, 2019 21:31 UTC (Mon)
by excors (subscriber, #95769)
[Link] (5 responses)
There's already a system for that: https://what3words.com/about/ . More universal than street names and numbers, more precise, much easier to translate to GPS coordinates, easy to communicate and to remember. It appears there is no diseased.merry.screwdriver, but there is a displeased.merry.screwdriver in the ocean near Hawaii.
Posted Jul 8, 2019 22:44 UTC (Mon)
by Jandar (subscriber, #85683)
[Link] (4 responses)
What is more northern, "reopens.rooks.divide" or "boil.stones.closet" and which of the two is nearer "hollies.shivered.octagon". As "reopens.stones.octagon" shares parts with each of the former three, has it something in common with them?
what3words.com has nothing to do with meaning, these combination are simply random but memorable ids. The meaning of these ids are stored in a database not in the three word combinations themselves.
Posted Jul 8, 2019 22:55 UTC (Mon)
by Jandar (subscriber, #85683)
[Link] (2 responses)
The names are mapped algorithmic to coordinates, so they have (in the strictest sense) meaning. Only this meaning isn't discernible for humans.
Posted Jul 9, 2019 5:58 UTC (Tue)
by micka (subscriber, #38720)
[Link] (1 responses)
Posted Jul 9, 2019 7:41 UTC (Tue)
by Jandar (subscriber, #85683)
[Link]
What3words is a solution for the problem where you communicate addresses verbally and store them in your human memory but use a computer while trying to find them.
Fortunately the Indo-Arabic numeral system is used nearly everywhere so if I communicate GPS coordinates to another computer-user she can understand and store them without problems and instead of using map.what3words.com uses www.openstreetmap.org.
Posted Jul 10, 2019 17:13 UTC (Wed)
by tao (subscriber, #17563)
[Link]
Streets, and geographical naming in general, is a mess.
Posted Jul 3, 2019 19:51 UTC (Wed)
by smadu2 (guest, #54943)
[Link] (1 responses)
Versions are "Year.Month" - so just looking at the version I know exactly when it was released and how long it's going to be maintained for.
Posted Jul 3, 2019 20:44 UTC (Wed)
by admalledd (subscriber, #95347)
[Link]
Yes, plenty of easy to find mappings online/wiki but is it truly necessary at this point? Useful, yes for marketing and that saying a name is better than a number for development/community stuff too. For those of us who are downstream users/administrators with fleets of machines to think about (and not just my personal computers!) I feel that simple numeric (recommended to have a prefix as article mentions too though so you know 'debian' vs 'vendor') is much nicer to have available in common use throughout.
Posted Jul 4, 2019 7:13 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
Posted Jul 4, 2019 7:50 UTC (Thu)
by juliank (guest, #45896)
[Link] (5 responses)
1) Using "upgrade" is not necessarily the proper way to upgrade in stable releases, and "dist-upgrade" (or "full-upgrade" as its known in apt(8)) is not just for distribution upgrades.
2) Using "stable" will be entirely safe for users in buster and following versions, as APT will not just switch to a new stable, it will detect the codename changed and refuse to fetch the new metadata (apt(8) prompts you to confirm the codename change, apt-get(8) requires a command-line switch).
The article also got things wrong in that it talks about "apt-get upgrade" when "apt upgrade" is meant and used in the email (the latter installing new packages, the former not).
Posted Jul 4, 2019 10:32 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (2 responses)
Posted Jul 4, 2019 12:19 UTC (Thu)
by juliank (guest, #45896)
[Link]
> trained themselves to do a apt-get dist-upgrade instead of a regular apt-get upgrade to pick up new package versions
I understand that sentence to say that people use dist-upgrade, even though upgrade supports installing new packages - this is only true for apt upgrade, though, and a reason apt-get upgrade is avoided.
And, as explained, dist-upgrade cannot cause any problems anymore starting with buster, as apt won't even download the metadata for the new release, so you'll be stuck on the metadata of your stable release until you confirm that the stable release changed.
Posted Jul 4, 2019 22:58 UTC (Thu)
by glaubitz (subscriber, #96452)
[Link]
Posted Jul 4, 2019 16:00 UTC (Thu)
by smcv (subscriber, #53363)
[Link] (1 responses)
This avoids installing a 2-years-later distro unexpectedly, but users who hit this error case will stop getting security updates, so it seems like a stretch (no release codename pun intended) to call it safe. (It's certainly less unsafe, and seems better than what used to happen.)
Posted Jul 7, 2019 12:25 UTC (Sun)
by zwenna (guest, #64777)
[Link]
What juliank failed to mention that this also applies if the Suite changes, e.g. from testing to stable. This has already lead to some questions on debian-user mailing list:
https://lists.debian.org/debian-user/2019/07/threads.html...
> This avoids installing a 2-years-later distro unexpectedly, but users who hit this error case will stop getting security updates, so it seems like a stretch (no release codename pun intended) to call it safe.
Indeed, and it means that two years from now when bullseye is released and buster becomes oldstable, _everyone_ suddenly no longer receives updates by default. Should I ask for a CVE entry already?
Posted Jul 5, 2019 1:49 UTC (Fri)
by mirabilos (subscriber, #84359)
[Link]
But otherwise, the release versions (9, 10, 11…) are not used *at all* inside Debian, and people remember the lower-entropy codenames more easily. The ordering is a bit of a problem, but easily looked up, and if one regularily backports to ancient distros they’re easy enough to remember. So I’d keep them out and perhaps just use the codenames even _more_.
Not installing a system with the moving alias (“stable”) by default sounds sensible, though.
Posted Jul 6, 2019 2:37 UTC (Sat)
by flussence (guest, #85566)
[Link]
Posted Jul 6, 2019 9:39 UTC (Sat)
by amacater (subscriber, #790)
[Link]
That process of rebasing the symlinks for releases is essentially happening more or less now.
We know the names of the next two Debian releases well in advance. Debian releases when it's ready: a year based timeframe doesn't really work: you don't want to have to speed up a release / testing to fit it to a defined date. [See also Red Hat pressure for twice yearly point releases / Ubuntu / Windows 10 ... ]
Codenames work for many of us: stable/testing/unstable are useful shorthand for some purposes: numeric releases work for some people.
Buster/bullseye/bookworm is the next sequence of releases: I can tell you that unless there are huge changes, bullseye _will_ be Debian 11 and bookworm will be Debian 12 but I've no idea when that will be.
When the FTPmasters finally push the new release out and restart the mirroring process, then anything that's been held through the last stages of release will flood to bullseye (and possibly buster-backports in due course) and we begin again.
Posted Jul 9, 2019 7:40 UTC (Tue)
by anton (subscriber, #25547)
[Link] (4 responses)
Posted Jul 9, 2019 8:52 UTC (Tue)
by zdzichu (guest, #17118)
[Link] (3 responses)
Posted Jul 9, 2019 9:53 UTC (Tue)
by rschroev (subscriber, #4164)
[Link]
If the code name is meant to be the main version identifier, it should be used everywhere, instead of a strange mix of code names here and version numbers there.
It doesn't help that there is no obvious way to find the correspondence between code names and version numbers. Maybe there's a list on debian.org, but I can't find it. I can find a list on Wikipedia, but shouldn't a project's own website be the primary source of information for such things?
Also, /etc/os-release is a relatively recent addition. For most of Debian's history, /etc/issue is all we had (or lsb_release -d, but that's not in the standard installation).
Posted Jul 10, 2019 17:16 UTC (Wed)
by tao (subscriber, #17563)
[Link] (1 responses)
Posted Aug 2, 2019 11:29 UTC (Fri)
by mgedmin (subscriber, #34497)
[Link]
> The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if it is missing. Applications should not read data from both files at the same time.
so it would be wrong to use /usr/lib/os-release instead of /etc/os-release, in theory.
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
But defaulting to a world where sources.list does not point to "stable", which suddenly changes at release time, seems like a goal worth pursuing.
One of the installer developers pointed out that Debian installations have defaulted to using codenames in sources.list since 2005.
Debian and code names
Version numbers should be... numbers
There are too many systems to keep track of every idiosyncratic version numbering scheme. If you have to memorize anything, you're doing it wrong.
</p>
<p>
Internal to a group it's okay to have a funny code name. But external users have many other things in their life beyond your software. Asking them to memorize code names forever is unreasonable.
</p>
<p>
Version numbers should be.... numbers. If the number is bigger, then it came later. If it's structured, use simple semantic versioning (X.Y.Z) where again you only need to compare numbers. When you do that, everyone can understand what they are. (Dates can work that way too if you make them YYMM or some such... but do it in a way that it's obvious how to compare them as numbers.)
</p>
Version numbers should be... numbers
Version numbers should be... numbers
Debian and code names
It is Buster, the friendly doggo
Codename do have meanings
It would be a shame to waste such effort!
Debian and code names - pets or cattle
Now days we often have some many of the things that they are sa13-254 etc. Just like we might identify cattle.
Debian and code names - pets or cattle
Debian and code names - pets or cattle
Debian and code names - pets or cattle
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Names always alphabetical so I have some sense of where in the whole suite of releases I am.
Debian and code names
Debian and code names
Debian and code names
Debian and code names
The article also got things wrong in that it talks about "apt-get upgrade" when "apt upgrade" is meant and used in the email (the latter installing new packages, the former not).
The article and the mail are correct in this. Because "apt-get upgrade" does not fetch new packages, users (including me) always used "apt-get dist-upgrade". "apt upgrade" does fetch new packages but users are only slowly migrating. The mail claims that "apt-get dist-upgrade" (and presumably also "apt dist-upgrade") can cause problems if "stable" has changed in the interim. Others point out that a default installation uses the codename (eg "stretch") and not "stable" in the sources.list, so this problem will not occur.
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names
An annoying aspect of Debian (and Ubuntu) is that /etc/issue only shows the version number, while everything else (e.g., packages.debian.org) uses the codename.
Debian and code names
Debian and code names
Debian and code names
Debian and code names
Debian and code names