On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: > On Sun, Jun 11, 2023 at 05:58:50AM -0400, songbird wrote: > >> Tixy wrote:
>>> Or maybe the wiki page should be deleted, or just say go RTFM, >>> i.e. read the release notes for the release you want to upgrade >>> to. >> >> except that is a misconception for those who are running testing. >> we're not upgrading to a new release. > Hi Songbird and all, > > I may go and have a crack at editing the wiki pages in a few > minutes. Hint: Anybody with a wiki account can edit the wiki - it > really is a wiki. > > Release names and codenames: > > This is a subject that has been fairly well explained over the > years. Debian 1.0 never actually got released - someone took > pre-release links and rebranded them as "Debian 1.0" for a CD > release. At that time, Debian took on the idea of release names to > stop this happening again. > > If you follow the release name in your /etc/apt/sources.list it will > follow a release from testing -> stable -> oldstable -> > oldoldstable. > > If you track "testing" (something which has been deprecated for a > while) What? Since when? This is the first I remember having heard of this. Certainly the "continuously usable testing" thing seems to have not gone anywhere, or otherwise stalled - but that doesn't mean that testing isn't usable, or useful, or that tracking it is impractical, or anything of that nature; just that you have to expect that by doing so you will occasionally see things break, e.g during library transitions, and have to wait for those things to be resolved. > then you must expect that it will change very unexpectedly on a > release and then large changes immediately after as everything else > catches up with being unfrozen. Of course it will. I actually look forward to seeing that happen, and watching the flood of new package versions come in after a new release. But that doesn't mean that we should be presented with this opaque "this thing has changed, so we're going to refuse to update at all till you do something to approve that change; here's a reference to a man page which briefly mentions something about the technical details of why this happens, but doesn't explain anything about how to approve the change, or point to any other documentation which does explain that". We *are already tracking testing*, *by that name*. We *know* that when a new stable is released, the release codename that is in testing is going to change. That is *expected*. It is aggravating to see this prompt at all - let alone to see it again and again, once every few years, and have to dredge into my memory (since it's been a few years since the last time I needed the information) for where to look to find the correct incantation to actually bypass it. The same thing applies to those who track 'stable' by that name. Using the symbolic names for the releases, rather than the actual codenames, *is semantically different* and the tools *should treat it differently*. I could achieve the same practical result by using the release codenames, and manually editing sources.list after each release - but that loses out on the *convenience* factor, as well as being conceptually inappropriate; if you have something that has to be done over and over in exactly the same way every time, on a computer, and you are not automating it, you are Doing It Wrong. Using the symbolic names should make it possible to avoid those manual steps, and in fact it used to do just that, but it no longer does. As songbird said: it should all "just work". I'm actually startled that, judging from the fact that your responses have been centered on explaining the use of Debian codenames, you seem to have so completely misinterpreted the objection being raised here. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
