On 2023-06-12 at 18:55, David Wright wrote: > On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 17:36, David Wright wrote: >>> There are several sources: > > [ snipped the back and forth ] > > I'm sorry, but I just can't take seriously your not being acquainted > with the term "release". Please don't put words in my mouth. Of course I'm familiar with that term. I just don't think of it when updating, perhaps in part because I update routinely when a release has not happened. Regardless of what you can or cannot take seriously, the fact is that in *none* of the cases thus far when I have encountered this message did the term "release" occur to me as something that I might search for, except in hindsight after having already encountered the '--allow-releaseinfo-change" argument name. >>> 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. > > AFAICT the file InRelease is always accompanied by Release and > Release.gpg files. That seems plausible, though again it's an implementation detail which the end user doesn't need to know about, and was not referenced in the presented messages. In case it helps make my perspective more comprehensible: I've been seeing the term "InRelease" for all these years, in the output of 'apt-get update' as an apparent file file which is being downloaded and presumably parsed. There's never been any information provided as to what it is, and there's been no apparent benefit to trying to find out. (There are other terms used in that output, such as 'rred', which it seems entirely fruitless to even attempt to find any documentation for; I've actually found an explanation for that such-as example once, but don't remember the explanation, and have never been able to find it again.) Based on that experience, I no longer think of 'InRelease' as being anything but an unexplained internal detail of the 'apt-get update' process - one which it shows during its progress messages because that makes a helpful landmark for keeping track of where in the update process you are, in case there's a need to troubleshoot an issue. It has connotations in my mind of an opaque, discrete object, which there is no point in investigating or thinking about except in terms of that "here's where the failure occurred" type of troubleshooting. I certainly don't think of it as being a reference to a codenamed "release", except perhaps by some historical origin of the filename; I don't particularly think of it as *not* being that either, however, because I simply *do not think about it at all*. I'd have been as likely to think that its name referred to the releases of individual packages which are indexed within the file (i.e., "packages which are in a released state"), or something like that, as to think that it referred to a codenamed Debian release - if, again, I bothered to think about it at all. ...I've forgotten why I was writing the above paragraphs, or if there was a concluding point I was trying to reach, although if there was I think I'd have covered all the necessary ground before the point itself. >>> 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. > > Seem like tilting at windmills to me. Either blocking updates which would change this information protects against something, or it doesn't. This is the only meaningful thing that I can think of that it could be protecting against, aside from cases where people didn't realize that what they were using was a symbolic name. If it does meaningfully protect against something that applies in my case, then I want to retain that protection. If it doesn't, then that's one less argument for why it should be done at all. >> 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. > > Well back then, as best I recall, most packages were configured with > files called, basically, /etc/package.conf(ig) or under > /etc/package/ when the package was more complex. The main exceptions > were the traditional well-known unix configuration files. That much is true. Exactly which "package" would be relevant here, however, was less so - particularly given that the program names being used were 'apt-get' and 'apt-cache' and the like, not the much newer 'apt'. I do not dispute that it's a reasonable thing to have thought of. I just didn't, at the time (which makes it seem, to me, less obvious), and wanted to know how you came to it. >> 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? > > That's difficult to do for someone who doesn't recognise bookworm > and trixie as "releases" I recognize how this description can seem reasonable from your perspective, but again, to me it feels like putting words in my mouth. I'm having difficulty figuring out a way to describe how/why, however. I think this just reflects how wide the gap between the way you think about these things and the way I think about these things is. I was attempting to pursue one relatively narrow, and therefore hopefully more tractable, road to closing some part of that gap. If you don't find it worthwhile to attempt to do so, however, then I suppose this can stop here. > or InRelease being two words smashed together to avoid the > inconvenience of white space. Again, while I can understand how you could get to this from what I've written, this feels like an uncharitable description and possibly (though not definitely) an unwarranted degree of hostility. As before, however, every time I've tried to put a reason why - or an alternate explanation of my perspective on this, which might make more sense - into words, I've run into some kind or another of wall. I suppose I should just stop trying to argue for my perspective on these mailing lists at all; I can't even remember the last time it went anywhere positive, or even necessarily didn't go somewhere unfortunate. -- 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