Public bug reported: [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. ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1814727 Title: Backport never pinning and Packages-Require-Authorization Status in apt package in Ubuntu: New Bug description: [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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1814727/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
