Control: tags -1 + pending On Thu, 2 Feb 2023 Raphael Hertzog <hert...@debian.org> wrote: > (Adding Colin Watson as he might have feedback on Ubuntu's uses > of the various Release fields and on the likeliness to fix/change them) > > Hello, > > On Wed, 01 Feb 2023, Paul Gevers wrote: > > > I fear I've probably forgotten most of these details, so please pardon > > > me for this response… Wasn't the problem for Ubuntu that 'Pin: release > > > foo' also applies to foo-proposed too? I think 'Pin: release > > > foo-proposed' will work as intended though, right? Is the latter what > > > we'll start generating with this? Seeing some example generated pins > > > (before / after the patch) would be great to help reason about this. > > > > The patch also removes the "a=" from the pinning for the default release (at > > 990) and I think that will break Ubuntu's setup as the packages from the > > proposed pocket will suddenly satisfy this pin too. What you (Iain) > > discussed above works for the pocket/foo-proposed part, but I think Raphael > > needs the other part too. I fear that without additional options, we can't > > really fix this. > > At this point I need neither part because I have added "Suite" names in > Kali. But I think this behaviour is still entirely unlogical and will bite > others in the future. > > I would suggest to: > - apply the first hunk of my patch since this one seems to be fine > - skip the change for the default release > - document the limitation in --apt-default-release that it will only > match packages from archives where "Suite" or "Archive" has this value > (and maybe point back to this bug to find the context) > > > > I guess a test covering this for all of the Ubuntu, Debian & Kali cases > > > would be helpful in terms of confidence both with this change and making > > > any future changes here. The one thing I do remember is that it's hairy, > > > like all the pinning stuff in autopkgtest. :-) > > > > Yes. In the same area; for Debian I once had a proposal to set the > > Default-Release instead of using the pinning, but that broke Ubuntu's case. > > Indeed, as I shared in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002819#10 > Default-Release is actually implemented with the same code as the > suggested pinning. > > > It would have reduced another hairy part of autopkgtest tremendously, where > > a lot of sed/awk/grep-ing happens in the testbed to figure out which version > > of the source to install for the test. But alas, autopkgtest needs to > > support the Ubuntu archive. > > To be fair, the set of available fields to describe a repository are not > very good, not very well documented and not easy to grasp.
I think I accidentally fixed this bug in this MR: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/425 and in particular in: https://salsa.debian.org/ci-team/autopkgtest/-/commit/6b6183ead2fcbe80 That's work I did because I was unhappy of how pinning was done (with special cases for when pockets are used), and of my understanding of it. Note that in the new code pinning is never done with a= (or n=), so it will work with both suites and codenames. This also works with the Ubuntu use of codenames and suite names, but getting it right required full understanding of "priorities of apt preferences", in particular "general form" vs "specific form", and effects of preference ordering. @Raphael: if there are ways in which the Kali use case of autopkgtest different from Debian's and Ubuntu's ones, I'd be happy to add tests for them. In the MR above, see the tests/autopkgtest diff to get an idea of how we can test pinning by setting up a test archive. Cheers, Paride
