Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote:
> On 2023-06-11 at 09:05, David Wright wrote:
> > 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:
>
> >>> 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
>
> Where did you come up with the 'release' search term?
There are several sources:
Project News
News and Announcements about Debian
10June2023 Debian 12 "bookworm" released;
(remove the inflection from "released".)
apt/apt-get man pages use release in their SYNOPSIS sections;
From the term "Release Notes";
From conversations on debian-user;
(search for "release", and the most recent 100 matching posts
in 80,000 have a date range of just two months.)
From the error message printed when the release change fails,
or the confirmation when it succeeds (IIRC);
(Since the time when signatures were included in Release files,
"Release" has been heavily camouflaged with the prefix "In".)
From the apt-secure man page, which is mostly about Release files.
> I don't remember what I searched for in the apt-get man page when I
> first encountered this message, but whatever it was, I didn't find
> anything relevant.
>
> Regardless, the apt-get man page isn't the one to start with, because
> it's not the one the error message directs you to. The error message
> directs you to the apt-secure man page, which does not provide any
> useful information about how to resolve the error message.
Granted, that note might be improved, but as it was apt-get
that provoked the Error message, it would be natural to check
out its man page too.
> The error message also does not include the string 'release', in any
> capitalization variant, so that doesn't provide a hint for what to
> search for either.
AIUI, it contains the string InRelease, according to
https://lists.debian.org/debian-user/2023/06/msg00392.html
in this thread. Debian's use of camelCase makes it easy to
decompose the word. As pointed out above, the man page that
the Note directs you (apt-secure) to uses Release rather than
InRelease in all but two places.
> > 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.
>
> I've seen that (by searching that page for 'releaseinfo', after I saw
> the option mentioned in this thread today), and am considering whether
> to apply that configuration setting, or even to just alias 'apt-get' to
> 'apt-get --alow-releaseinfo-change' or one of the field-specific
> sub-options.
>
> However, this seems like a potentially poor idea, for a minimum of two
> reasons. One, I don't want to apply this behavior automatically to
> *every* repository I might configure, only to the Debian repositories.
> Two, I want to apply it only to repositories which are configured with
> the symbolic names, not with the release codenames.
I don't know whether or which of your extra repositories use stable/
testing as suites/codenames, so I can't opine on that.
> I'm also undecided as to whether I want to apply it between releases,
> but I suppose if not, that's an argument for retaining the existing
> behavior.
I don't know what "apply between releases" means. Isn't configuring an
APT option just the same as deciding to add --allow-releaseinfo-change
when you run apt-get in future?
> (Also, it's non-obvious from the mention "Configuration Item:
> Acquire::AllowReleaseInfoChange" where and how to apply this
> configuration setting, just as with every other mention of such settings
> in that same documentation. I've seen such things often enough over the
> years to have the information somewhere in the back of my mind, and to
> be able to dig the location back up with only minimal difficulty, but
> someone who's never interacted with APT configuration settings before is
> certainly not going to find it "very simple" to figure out how to apply
> that setting.)
I thought /etc/apt.conf was the obvious place, though nowadays, of
course, most sysadmins would likely drop a file into /etc/apt.conf.d/
as this makes changes easier to maintain. (Lots of Debian packages
now allow you to use foo.conf.d/ rather than directly editing the
foo.conf file itself.)
Cheers,
David.
Reply to: