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? 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. 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. > 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'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. (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.) -- 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
Attachment:
signature.asc
Description: OpenPGP digital signature