Usage of --pin-packages=kali-dev=src:foo results in a file like this
in /etc/apt/preferences.d/autopkgtest-kali-dev

Package:  foo
Pin: release a=kali-dev
Pin-Priority: 995

Unfortunately the "a=kali-dev" only matches on the "Suite" or "Archive"
field in the Release file, and not on the "Codename" field (which in my
caces was the only field available).

I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses
another syntax that seems to cover more cases:

Package: *
Pin: release kali-rolling
Pin-Priority: 990

However that syntax doesn't seem to be documented in apt_preferences.
If it's correct and allows to check on either of the 3 fields, then
we should likely use the same syntax in both files.

Otherwise I would like to suggest to create two entries, one with
"Pin: release a=foo" and one with "Pin: release n=foo" so that
we are sure to match on any of the 3 fields.

Cheers,

Control: tags -1 + patch
Control: user devel@kali.org
Control: usertag -1 + kali-patch

I got confirmation from David Kalnischkies that this syntax is supported
and means exactly this:

12:54 <DonKult> buxy: yeah, its supported and means "Archive/Suite: or
Codename is X". One example in the manpage actually includes it (release
unstable), but it is never explained it seems. It is also the backbone of
commandline flag -t X. Code is in apt-pkg/versionmatch.cc, but its not
much to see.

So I recommend to use this same syntax in files generated for
--pin-packages.

Suggested patch is attached.

Cheers,

Hi Raphaël,

Thanks for reporting.

I'll have to check and think about this. I remember that I had lots of
issues with coming up with changes to autopkgtest that also worked for
Ubuntu, as they use the same Codename for the real Suite and the
*-proposed Suite (which they call pocket). I don't recall if that was
with respect to pinning or other aspects of autopkgtest and it's
requirement to manipulate where packages should be installed from.
Before committing your proposal I need to understand that I'm not
breaking existing valid configurations too.

Paul

Hi,

I saw a comment mentionning this, but it was related to the "--apt-pocket"
option and I didn't change that part, which still uses the "a=foo" syntax.

https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263

And indeed in http://archive.ubuntu.com/ubuntu/dists/jammy-proposed/Release you have

 Suite: jammy-proposed
 Codename: jammy

Cheers,

Hi Raphael,

Right, thanks for referencing that line as it has the bug number where
the relevant information was. As the --pin-packages option will already
have the *-pocket in the name, I think this would work for Ubuntu too.
CC-ing Iain for a sanity check on our reasoning.

Paul

Hey Paul, Raphael, happy new year to you,

Thanks for copying me on this. Julian might be a good one also.

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.

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. :-)

Cheers,

Hi,

Sorry it took so long.

Done now.

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.

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. 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.

Paul

(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,
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)

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.

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,