On Thu, Jul 13, 2023 at 11:09:02AM +0100, Dimitri John Ledkov wrote: > On Thu, 13 Jul 2023 at 10:27, Julian Andres Klode > <julian.kl...@canonical.com> wrote: > > > > Hi folks, > > > > I just got reminded that when we wrote the initial phasing code > > we made it not apply in chroots to avoid breaking builders and > > things. > > > > I'd like to remove that check because it's a bit unexpected. To > > do that, I'll probably add an option to override the chroot check > > to apt soon for 23.10 and then we can drop the check in 24.10, or > > 24.04 even. > > > > When the initial code was written, phasing was implemented using > > policy and respected by the install command. Since then, phasing > > has moved to the upgrade calculation, using keep back, so there are > > significantly less concerns as installs no longer respect phasing, > > so image building is not affected anymore, but upgrading build chroots > > would be. > > If proposed is enabled, and pinned up, can the phasing be ignored on > the updates pocket? > Or is there a pinning preference we can use, to again update all our > chroot code to ensure unphased upgrades are done?
Phasing is not affected by pinning you need to set: APT::Get::Always-Include-Phased-Updates "true"; I do not think encoding that enabled proposed implies no phasing is a good idea, because apt shouldn't know specifics about what suite names mean. But then again, the phasing code knows about -security right now, because it disables phasing if there's a security update between the installed and the phased version (as it cannot switch candidates, only keep back). Optimally one day a new solver enables us to um not need to know that (solver draft: https://magenta.jak-linux.org/bin/solver3.pdf | https://salsa.debian.org/apt-team/solver3). -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel