On Thu, Aug 25, 2022 at 06:13:12PM +0200, Lukas Märdian wrote: > Actually, there is a 4th option:
> 4/ Static PPA build: > We could fork Jammy's src:systemd package and adopt it to ONLY build a > "systemd-repart" binary package, possibly as a static build. This should > conflict with systemd >= 251 to notify users on upgrades about the situation. > Such PPA could be maintained by the ubuntu-foundations team and would not > require duplicated maintenance work. It should be relatively easy to > integrate this into mkosi's "install_debian_or_ubuntu()" method [2], where > apt repositories are set-up and packages installed, anyways. > Would this be a viable option as well? It would have the lowest impact of all. Provided that the use of a ppa would work for upstream's CI requirements, I think this is the lowest-cost option and would prefer we do this. However, if that's not an option, I would accept the addition of a systemd-repart binary package in jammy as an SRU. > Am 25.08.22 um 12:11 schrieb Lukas Märdian: > > 3/ Universe: > > We could adopt Jammy's stock src:systemd package to build systemd-repart > > and ship it in an isolated "systemd-repart" package (in universe), as > > suggested in my initial post. FWIW, this should be compatible with > > Ubuntu's SRU policy: "For Long Term Support releases we sometimes want > > to introduce new features. They must not change the behaviour on > > existing installations (e. g. entirely new packages are usually > > fine)." [1] In order to not break any future upgrades, we'd need to > > introduce some "Replaces: systemd-repart/Provides: systemd-repart" > > statements into Kinetic++'s version of systemd, so that Jammy's > > systemd-repart package is uninstalled and replaced by the newer series' > > systemd binary package on upgrades. This replacement logic is something > > I could prepare and take care of in the newer Ubuntu versions. Using > > this option, we would not run into any duplicated maintenance effort, as > > Jammy's src:systemd could just receive it's SRUs and security updates as > > usual, while at the same time not imposing any unecessary risk to our > > existing users of the Jammy stable series. The new systemd-repart > > package would be residing in the universe pocket and only become active > > once installed explicitly by a user (or mkosi). There's still the risk > > of follow-up SRUs to the systemd-repart binary, as lined out by Robie, > > but IMO this is acceptable due to the lower threshold of universe SRUs > > (e.g. we might be able to hold back any sd-repart fixes until the next > > src:systemd SRU would be scheduled anyways). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel