(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. In my experience, Codename is the reference field that gives a canonical name. Suite is an alias that can move. And Archive is never used. The Ubuntu usage is not consistent with the above practice and they seem to use "Codename" as some sort of "Parent-Repository" or "Reference-Repository". There's no such field really and yet it would make sense to have one when you want to target all repositories that are compatible with a given release. I doubt that there's any chance that Ubuntu will fix their use of the Codename field but I'm putting Colin Watson in CC in case he can shed some light here. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
signature.asc
Description: PGP signature
