> > > > 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
signature.asc
Description: This is a digitally signed message part
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
