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.
