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

[Luca Boccassi]

> > > > Unfortunately, they're currently blocked on this because 22.04
> > > doesn't
> > > > ship systemd-repart. The upstream CI uses Github Actions which
> runs
> > > on
> > > > Ubuntu Jammy and will do so until the next Ubuntu LTS is
> released.
> > > 
> > > Can Github Actions not install software from any other source?
> For
> > > example, what if you were to put systemd-repart as a new package
> into
> > > a PPA, or into jammy-backports? Would Github Actions really be
> > > incapable of using this?
> > 
> > This is needed by users too. Forcing users to install all systemd
> > packages from an unsupported, random third party PPA that doesn't
> > provide security updates would not be a good idea for production
> > workstations, I think.
> 
> This justification applies equally to all software that any user
> might
> want backported to jammy-updates, though. What makes this request
> special enough that it should be granted an exception?
> 
> To be clear, this isn't a -1 from me. It's a "Needs Information".
> Maybe
> accepting this in a Jammy SRU is justified. But if so, I don't think
> the
> case has been made yet, and that's why I'm asking further questions.

The difference is that here it's the upstream maintainers asking for
this, not just users. From our point of view, not including repart in
Jammy was an oversight - there was really no reason to keep it
disabled, other than we noticed and asked for it too late, and we
should have asked for it sooner.
Not being able to rely on repart because it's absent from Jammy means
we have to accrue significant and expensive technical debt in mkosi,
that is making everything very fragile, so at some point we might just
have to cut our losses and leave Jammy unsupported - which would cause
a lot of friction and grief, given it will be popular and widely used
for many years among developers, so we are trying hard to avoid that if
possible.

Also other use cases can be reasonably solved by different means -
Flatpaks, Snaps, PPAs. None of that can work here, because the entire
set of packages from src:systemd must be at the same revision on any
given system.

> >                               It's really a lot of work for
> nothing,
> > given the risk is really zero - it's a new command line program
> that is
> > inhert and doesn't do anything until it's called manually...
> 
> On this point, I disagree. The risk is that there's an issue with the
> new binary, and you end up having to SRU it again to fix those
> issues,
> and so on. Sometimes the nature of such fixes impact risk in other
> areas, or to now-established behaviour. Or you don't fix it, and
> users
> expecting quality from the archive get a poorer experience than they
> would have had the binary not been added.

It's not a separate new source package though, so any bug fixes
appropriate for backporting are always included in point releases from
systemd-stable (which you pick for SRUs anyway? If not, you really
should start to, we produce those specifically for distros :-) ), and
this component is no exception.

> On the other hand, putting this in a PPA or in the backports
> pocket[1]
> is easier from the risk perspective. So I'd really like to see a
> proper
> justification of why it is necessary to put this in the updates
> pocket.

As mentioned an unsupported PPA is really not a viable option. jammy-
backports is slightly better, but again it means updating the _entire_
systemd stack to the new backported version, which it seems to me
carries way more risk for users than the additional executable from the
same version? Presumably it would need to keep being updated to new
versions, which means there's an even greater risk of changes to
established behaviours.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220817/f775d148/attachment.sig>