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