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

Thu Aug 25 10:11:46 UTC 2022

Hi Luca, Robie & other SRU members!

Am 17.08.22 um 18:43 schrieb Luca Boccassi:
>>> The critical difference is that this is not a separate and
>> standalone
>>> utility...
>>
>> Yet this is the justification you're using as to why an SRU will be
>> safe.
> 
> Runtime behaviour and maintenance/development workflows are very
> separate and independent matters, and I've explained that at length
> already.
> 
>> It seems to me that it's perfectly possible for you to arrange a
>> build
>> of a static binary in a PPA, and use that to solve your problem.
>>
>> You are also implying that the binary will not need to change again,
>> so
>> there's basically no technical debt there as far as I can tell,
>> contrary
>> to your previous claim. Especially as you're upstream for it too, so
>> it's not like that's going to end up "behind" for security any more
>> than
>> the official Ubuntu repository that would depend on you anyway.
>>
>> If you don't want to ship a single binary in a PPA, then that's up to
>> you. But you can't justify your request on the basis of your
>> inability
>> to do that, when actually it's simply your refusal to do that at the
>> cost of additional risk to Ubuntu users.

I totally understand Robie's concern (wearing his Ubuntu SRU hat), trying to avoid any risk to users of Ubuntu stable series as he should be! We have had those policies in place for a long time and for a good reason. They proved to be very effective in providing our users with very usable and stable releases.
We should continue to apply those rules as strictly as possible, to avoid any risk of regression.

> It is not 'perfectly possible'. We are not going to completely overhaul
> our development and maintenance practices and commit to a ton of extra
> work (forever) for the sake of a mistake in the build-time
> configuration of src:systemd in Jammy, sorry.
> 
> There are two possible outcomes here:
> 
> 1) The executable becomes available, either in the main package or in a
> new binary one in universe
> 2) Ubuntu is dropped as a supported platform for systemd developers,
> and when they find out things don't work we tell them to switch their
> machines to Debian/Fedora/SUSE/Arch/etc

I've had another close look at the Backports [0] & SRU [1] policies and at what mkosi is doing in detail [2] and came to the following conclusion:

We have 3 options available:
1/ Backports:
We could publish a systemd-repart enabled version of src:systemd in jammy-backports. In order to avoid getting into conflicts with SRUs or security updates to the stock version in jammy-updates/-security, we could actually backport the new major version of systemd v251.4 from kinetic, which has sd-repart enabled by default (and some more goodies).
Someone would need to support this backported package for the lifetime of Ubuntu Jammy LTS, though. Upstream's 251.x point-releases are a good starting point for this, but it's certainly some extra burden for the backporter.
Furthermore, backports are supposed to "provide new versions of standalone applications which can be safely updated without impacting the rest of the system", according to the backports policy [0], which does not really apply to src:systemd, so we'd need an exception for getting it into this pocket, too.

2/ PPA:
In a similar fashion to -backports, we could provide a PPA containing a systemd-repart enabled version of systemd 249. This is something that could potentially be done by the ubuntu-foundations team, so it doesn't need to be a "random third party PPA" and 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. Sure, updating the full systemd suite would use some extra bandwith, but that's not too bad IMO.
The issue I see with this option is the committment and duplicated maintenance effort of the ubuntu-foundations team to keep stock systemd and repart/PPA systemd in sync and the PPA version number ahead of -updates (for the lifetime of Jammy LTS). And not to cause any conflicts with SRUs or security updates, such that mkosi would fall back to installing the stock version due to a higher version number.

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).

All things considered, I very much prefer option (3) "new systemd-repart binary in universe", and if there's no strong opinion against this from the SRU team (Robie didn't explicitly state a "-1", but rather tried to assess the risks involved), I'd like to move forward with this. Thank you Luca for, your offer to help preparing such package split for Jammy, it is much appreciated that you're supporting Ubuntu's systemd (even in your free time)!

> I've worked out of my free time to provided the MR, testing, and the
> bureaucratic homework for the first one as I believe it's in the best
> interests of all parties. I've also already committed to provide the
> changes for a new temporary binary package if that's the preferred
> approach, and I am still happy to follow-up on that committment. I very
> much prefer the first option.
> 
> If on the other hand the second option is the preferred one by the
> Ubuntu team, then please let me know and we can cut it short.

That's certainly not the intented outcome here, as both sides will loose in this case.
Let's try to work together and resolve this siutation!

Cheers,
   Lukas

[0] https://help.ubuntu.com/community/UbuntuBackports
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
[2] https://github.com/systemd/mkosi/blob/main/mkosi/__init__.py#L2499