Enablement of systemd-repart in Jammy LTS (post-release)

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220825/5cfc7530/attachment.sig>