On Thu, Dec 9, 2021 at 11:27 AM Colin Watson <cjwat...@ubuntu.com> wrote:
>
> On Wed, Feb 03, 2021 at 11:12:57AM +0000, Iain Lane wrote:
> > I think the Launchpad support is still missing, although we started on
> > this several years ago. That will need to be picked up and finished off:
> >
> > https://bugs.launchpad.net/launchpad/+bug/1016776
> >
> > That bug report talks about doing it pre-release (for devel only) but I
> > think I'm now in favour of doing it always, and the proposed
> > implementation in there would allow that. For devel, the main reason is
> > that I frequently come across users who have misunderstood what proposed
> > is for and manually enabled it themsleves, resulting in various degrees
> > of brokenness on their systems and bug reports that take developers'
> > time to triage and eventually close. These are not (always) people who
> > have updated from a previous release, where we could have had tools
> > disable -proposed for them, but also people who have explicitly turned
> > it on after installing a daily out of an attempt to help test the
> > upcoming release.
> >
> > On the client side, as Robie says, we will at least need to update
> > documentation. I'm also not sure what update-manager will do if there
> > are NotAutomatic updates present. It might need some tweaking to show
> > them differently. This could be checked by looking at something in
> > -backports, which is already present with these flags set.
> >
> > And finally, there's some implication for package builds; both Launchpad
> > buildds and other builders would need to ignore this. Launchpad does
> > this for -backports currently, i.e. -backports builds get Build-Depends
> > from -backports wholesale; hoepfully that means the buildd side isn't
> > too hard because we can reuse that.
>
> This is now ready to use from the Launchpad point of view. There's a
> "proposed_not_automatic" flag on distro series exported over the API; if
> this is set to True, Launchpad writes "NotAutomatic: yes" and
> "ButAutomaticUpgrades: yes" to the Release file. We've also arranged
> for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad
> builds will ignore this; I can't speak for other build environments.
Just to clarify, people won't need to manually specify all
dependencies, right? For example, if testing the 'systemd' package
from -proposed, simply doing 'apt install systemd/jammy-proposed'
would install the proposed version of systemd *and also* the proposed
version of libsystemd0?
Also, is this really needed? Is it really so hard for people to just do:
$ sudo add-apt-repository -p proposed
...install proposed package(s) normally and do tests...
$ sudo add-apt-repository -r -p proposed
>
> Thus, from the Launchpad point of view this is ready to use, although
> somebody may want to check the behaviour of things like sbuild and
> pbuilder first.
>
> Somebody in ~techboard would need to make the actual change, if you
> think it's appropriate. For example, the following in "lp-shell
> production devel" would do it for all supported Ubuntu series:
>
> for name in ("bionic", "focal", "hirsute", "impish", "jammy"):
> series = lp.distributions["ubuntu"].getSeries(name_or_version=name)
> series.proposed_not_automatic = True
> series.lp_save()
>
> --
> Colin Watson (he/him) [cjwat...@ubuntu.com]
>
> --
> technical-board mailing list
> technical-board@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
