Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote:
> 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:
[ snipped the back and forth ]
I'm sorry, but I just can't take seriously your not being
acquainted with the term "release". Your reasons strike me
as rather like a car driver saying that they didn't know that
"No vehicles" or "No automobiles" applied to them.
The list has been buzzing with the term in anticipation
of release day.
> >> 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.
AFAICT the file InRelease is always accompanied by Release and
Release.gpg files.
> > 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.
> 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.
> 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.
As time goes by, there are examples where information is less focussed
on packages per se, particularly where DEs are involved and
configuration applies more to the whole environment than to individual
packages. But admin utilities, and Debian's own configuration, tends
not to be so monolithic, but more discretely focussed.
> 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" or InRelease being two words smashed together to
avoid the inconvenience of white space.
Cheers,
David.
Reply to: