Comment 0 for bug 1814727

Revision history for this message
Julian Andres Klode (juliank) wrote :

[Impact]
These are not driven from a direct user experience, but are related to other developments:

(1) unattended-upgrades could use the never pinning to disable repositories rather than switching candidates. That would simplify code quite a bit.

(2) Packages-Require-Authorization lets a repository declare that downloading packages from it requires authorization. This is useful both for private repositories, as it can prevent unattended-upgrades failures if you remove authorization info; and it also allows creating a new form of semi-private repository, where only pool/ requires authorization.

[Test case]
Tests are included in autopkgtests and cover the common scenarios.

https://salsa.debian.org/apt-team/apt/blob/master/test/integration/test-packages-require-authorization:
(1) Add repository with Packages-Require-Authorization and no auth.conf entry: pin -32768
(2) Add repository with Packages-Require-Authorization and a auth.conf entry: pin 500
(3) As (2), but a custom pin still applies

https://salsa.debian.org/apt-team/apt/blob/master/test/integration/test-policy-pinning#L365
(1) Test that Pin-Priority: never overrides both per-package pins and per-repository pins
(2) Test that Pin-Priority: never is only applied for per-repository (Package: *) pins

Tests in older releases should be the same, but it's not clear yet. Bug will be updated once the SRUs are ready.

[Regression potential]
The changes might introduce regressions in pinning. The pinning implementation in trusty is substantially different from the other releases, and should thus require more testing.