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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
