On 2023-06-11 at 17:36, David Wright wrote: > On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 09:05, David Wright wrote: >>> 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".) That assumes you've seen an announcement; this cycle, I don't think I had, and certainly not everyone will have been in a place to do so. > apt/apt-get man pages use release in their SYNOPSIS sections; As part of the "replace this with a real example of the class" keyword 'target_release', and not anywhere else. I certainly would not have thought of this as suggesting something to search for in the man page, or as being related to this error message. > From the term "Release Notes"; Release notes are not in my mind when I'm updating. That they are in yours indicates, as was probably already clear, that we think about these things differently. > 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.) I've been reading debian-user for years on end, and it did not lead me to think of this as a search term to try. > 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".) See below. > From the apt-secure man page, which is mostly about Release files. This could be interpreted as a hint, I'll admit, but it did not occur to me as one when I was looking at that page. >> 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. Indeed so, but I didn't find anything useful from searching for "update', which was the action I'd attempted to take. It did not occur to me to search for "release"; nothing I could see in the context brought that string into relevance. >> 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. I consider that to be part not of the error message, but of the repository identifier being referenced *by* the error message. (The same would be true for the labels 'bookworm' and 'trixie'.) It did not occur to me to use that as an indicator of what to search for, and if it had, it would have led me to search not for 'release' but for 'InRelease' - since I consider that latter to be a discrete term of its own. > 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. I don't think of "InRelease" as being a word, but as being a filename that's presumably used on the repository servers and checked for by the update tooling - i.e., as an implementation detail, which is irrelevant to anyone not attempting to investigate the innards of that tooling or those servers. >>> 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 --allow-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 wasn't thinking of it as applying only in cases where the symbolic names 'stable' and 'testing' are used; I'm pretty sure it would apply to any repository that uses a symbolic name rather than a release-specific codename, and there's nothing restricting symbolic names to those two. That said, as far as I recall I don't currently have any non-Debian-official repositories configured, which is one reason why I'm still considering taking this approach. I have had in the past, however, and I wouldn't want to have to remember to adjust this if I once again add one. The reason for both of the two reasons I gave is, I think, that I have the impression that this "prohibit updating against a changed codename unless explicitly approved" behavior is intended in part to protect against cases where the name was *not* intended to be a symbolic name, but the upstream repository has been taken over and changed (possibly legitimately, possibly maliciously). That scenario is one of the things I'd prefer to continue to protect against, for any repositories other than ones where I know the name in use is a symbolic name. >> 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? It's more or less the same as $ alias apt-get 'apt-get --allow-releaseinfo-change' but otherwise, if I'm parsing you correctly (which I'm not positive I am), yes. >> (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.) All I can say on that front is that when I first ran across mention of these configuration settings (many years ago, certainly well before the behavior the specific setting we're discussing was introduced), that file did not occur to me, and I had no idea where to start looking. I think I eventually found a man page somewhere which mentioned the filename, rather than just presenting the configuration strings with no indication of where to put them, but I don't recall for certain. Years after that, when I did decide that I wanted to set one of these configuration settings, I did manage to dig up the correct file - but I don't remember where I found the information, or how I came across it there. Can you articulate what it is that makes that configuration file name seem obvious to you as something to look for, when encountering a string such as 'Foo::BarBaz' in an APT context? -- 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