Bug#1058579: apt: gives misleading error when not finding Packages.xz in Release (not InRelease)

[Yann Dirson <ydirson@free.fr>]

Package: apt
Version: 2.6.1

# context

The repo is served as a "generic package repo" on gitlab.  As a first step I'm
putting unsigned Release file there, because setting sigs there is another
adventure.

So I have Release not InRelease, and since it's 2 packages I chose to spare
space using just a Package.gz, hoping for maximum compatibility (apparently
mistakenly so).


# observations

When updating, apt acknowledges it got Release not InRelease, but its error message
seems to imply it checked *InRelease* to find a *Packages* file:

root@debian:~# apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease           
Ign:3 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ InRelease
Hit:4 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ Release
Ign:5 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ Release.gpg
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
77 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: Skipping acquire of configured file 'Packages' as repository 'https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 ci/ InRelease' does not seem to provide it (sources.list entry misspelt?)


Using "-oDebug::pkgAcquire::Worker=1 -o Debug::Acquire::https=1" indeed shows no attempt
at downloading anything after Release.gpg


# my interpretation

There are 3 misleading items in the same statement:
* it likely did not check *InRelease* contents but really *Release*
* OK it did not find *Packages* but only after looking for *Packages.xz*, and since
  adding *Packages* back does work, it does not really push users to use the default
  compression format.
* the "sources.list entry misspelt?" suggestion feels to throw the user completely off-track:
  as it did find a Release file, the entry surely *does* point to a repo