Re: Integration with systemd
Hi,
On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> > That is work we have to do regardless of whether we want to support
> > alternatives or not, but in the simple case we just list what is supported
> > by the systemd version we have decided to ship in the last stable release,
> > so we can have backport packages with reasonable effort.
> It is not obvious to me why we would need a different policy for systemd
> than for other packages which backports may depend on.
We need *a* policy in the first place.
When a package requires a systemd feature that isn't present in the current
stable release,
- how do we detect this?
There is not even infrastructure in place that can map the features used in
unit files to required minimum systemd versions. Detecting dynamically used
features may be possible by looking at library symbols used, but this would
still have to be developed.
Right now, if I take a package from testing, compile it in a stable chroot
and get an installable binary package that has no dependencies not
satisfiable in stable, how do I verify that the package will work?
- how should we react?
If a backported package does not work, and we find out somehow, what is the
correct course of action? Should the package be removed from the backports
archive, and users told to upgrade to testing? Should the backporter create
workarounds for missing features?
If you look at the history of the Debian Policy, the question of backwards
compatibility has always been a major point of contention. It took several
years to implement the "build-arch" target in debian/rules, because there
was no reliable way to detect whether the target was supported, so it was
impossible to distinguish between a build failure and an old package.
For some reason, all that caution seems to have gone out of the window.
We have had systemd as default pid 1 for longer than it took to get
"build-arch" documented, added to policy as optional, transitioning all
packages in the archive and making it mandatory so autobuilders could use
it. In all this time the only mention of systemd in policy are two
instances of adding dh_installsystemd after a mention of dh_installinit,
and section 9.3.5., titled "Example", pointing to a manpage instead of
giving an actual example.
Debian is entirely unprepared to do backports of anything that uses newer
systemd features. For GNOME that isn't a problem, large installations will
simply wait for the next stable release and laptop users will switch to
testing, but for libvirt, that is going to be a big deal.
> > No, and that's not our job. There are a lot of people out there building
> > non-systemd systems.
> Data says: not really a lot.
Even if we limit our view to "Debian installations", there is no sensible
way to measure that, or to distill it down to a useful number. Is an
administrator for a large installation a single user? Should we look at
downloads or at popcon statistics? Do autobuilders pulling systemd-sysv as
a dependency of libgtk-3-dev count?
My point with that sentence is a different one though: a lot of Free
Software exists outside the Linux sphere that does neither anticipate nor
require tight integration with systemd, and that software is still useful,
so it makes sense to ship it. It is niche, but it is the niche we have been
traditionally good at, so I don't see a reason for leaving that and
focusing on an oversaturated field without even marginally preparing.
Mind you, we still need to cover that field, but the reason people have
forgiven us to usually be the last distribution to ship new versions is
that when we ship, we get it right -- and that's what I'm not seeing here.
We're not only short on volunteers to backport systemd features to
sysvinit, we're also short on volunteers to lay the groundwork for systemd
based services. Is that is an indication of "lack of interest", as it seems
to be when sysvinit support is concerned?
The other big elephant in the room is what Ansgar mentioned in his reply to
me: containers where the systemd instance lives outside the container. I
would expect that several users want to run "stable" systemd, and import
containers for specific services. What infrastructure, what policies are in
place to ensure that services inside the container are compatible with
systemd outside?
Simon
Reply to: