On Sun 11 Jun 2023 at 08:12:49 (-0400), The Wanderer wrote:
> 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.
>
> > 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.
It would seem very simple, the first time this happens, to configure
this in APT. I typed man apt-get (my preferred method), /release
and Space N three times, which showed:
--allow-releaseinfo-change
Allow the update command to continue downloading data from a
repository which changed its information of the release contained
in the repository indicating e.g a new major release. APT will fail
at the update command for such repositories until the change is
confirmed to ensure the user is prepared for the change. See also
apt-secure(8) for details on the concept and configuration.
Specialist options (--allow-releaseinfo-change-field) exist to
allow changes only for certain fields like origin, label, codename,
suite, version and defaultpin. See also apt_preferences(5).
Configuration Item: Acquire::AllowReleaseInfoChange.
Cheers,
David.
