On Wed, Dec 13, 2023 at 11:29:29AM +0100, Yann Dirson wrote: > 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?) Sadly, this relates to your later observation: > After more testing, it appears that the behavior is different > depending on the way the flat repository is used: […] > I'm a bit unsure whether this would be expected. The "funny" thing about flat repositories is that nearly everything can be one: http://deb.debian.org/debian/dists/sid/main/binary-amd64/ is e.g. a flat repository as well… unsigned and without any sort of hashes so apt will hate your guts by default, but with enough force it will gobble it up anyhow (it contains a Release file, but that is optional as well…). So… if a repository you added doesn't contain a Packages file there is a good chance that you misspelt something which happened to be still a valid repository. Perhaps nowadays, that apt even dislikes unsigned repos we could while not trim the support for these things at least review and edit messages assuming that users will nowadays only interact with proper repos… Messages referring to a repository will usually speak about InRelease as that is convenient to access from a code point of view. It doesn't mean the file is used – or even exists. Its just that the code who handles the file also handles if it doesn't exist, manages the fallbacks and so on. In an ideal world we would have an easier and better way of referring to a repository, but in this world we so far don't. There probably is an "upgrade path", but I don't have the cycles to think about it at the moment (nor while implementing part of that message a few years ago). It is somehwhat similar with how messages tend to talk nearly interchangeable about 'Packages' and 'Packages.xz' even if neither exists and we end up using 'Packages.gz' (and Packages.lz4). So, the gist is that yes, it can be misleading, but all individual parts are correct or have at least a good explanation. I also don't see a lot of ways to improve on it given that the message is already way too long and we can not go full analyse mode on untrusted data either… > root@debian:~# curl https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/ci/Release > Date: Wed, 13 Dec 2023 09:55:54 +0000 > Description: xen-guest-agent CI packages > Label: xen-guest-agent-ci > Suite: ci > MD5Sum: > 4bbd32da77623285b8a54ef926a1f028 277 Contents-amd64.gz > 9c8c7743a78d4c850fbdffac54c5e159 340 Contents-amd64.xz > 557f3042ec38f51a838d518739ecf4c2 925 Packages.gz > a3b82abf0ab81c4d5f829ec631c9deb8 1008 Packages.xz APT wants checksums for the uncompressed Packages file – even if they are not shipped in the repository – the info has to be there so that apt can check that the data it got after uncompressing is really the intended one. It will also be needed "later" for updates for the data as files could be stored (re)compressed [different compressor versions can produce different files having different checksums. Also, we tend to use compressions for storage which aren't available online to begin with], not to mention reverify, pdiffs, … I said wants as there is still support for repos who don't have hashes and so if you play your cards right, you could manage to make apt accept your repo, but please don't. Just provide checksums for the uncompressed files and be done. So, in summary, I am not sure what to do about this… on some level I agree, others I consider a user error, but if I look at the cost- benefit ratio of it all I don't see the parts changing that would need changing anytime soon so that this report has a very good chance of staying open until the heat death of the universe (or apt being removed from Debian, but that is only a theoretical possibility of course). Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature