Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Russ Allbery <rra@debian.org>]

The Wanderer <wanderer@fastmail.fm> writes:
> On 2020-01-03 at 13:35, Russ Allbery wrote:
>> The Wanderer <wanderer@fastmail.fm> writes:

>>> If the maintainers of systemd-the-package would be willing to not only
>>> split out these binaries into standalone package(s), but accept such
>>> init scripts for inclusion in those packages,

>> Why would that be necessary?

> Which part? The splitting out, or the accepting of the init scripts?

Both.

> The splitting out I think I've already addressed, if not directly or at
> length; I can go over it more specifically if desired, although I
> sometimes have a hard time phrasing things in that context in ways which
> aren't unintentionally provocative. The short version would be: to avoid
> undesirable side effects from other parts of the systemd package.
> (Again, it's been long enough that I forget what those side effects
> were, although I think they had to do with logind.)

So far as I can tell, installing the systemd package by itself shouldn't
do anything.  It's possible that I'm wrong, but if so, it might be easier
to just fix that problem rather than splitting out binaries.  It's also
possible that you ran into some long-ago-fixed bug and there is no longer
any problem with installing the systemd package on a system that isn't
running systemd.

I don't think there's enough information on this thread to indicate that
there's any need to split out the package.  Probably it would make sense
for someone to just try installing that package on a non-systemd system
and running systemd-tmpfiles and systemd-sysusers and see if anything
breaks.

> The accepting of init scripts seemed to me like an essential piece of
> making sure those scripts would be present wherever they would be
> needed. Your suggestion above seems to provide a way to make it less
> essential, and thus would make moving forward easier and more practical.
> The only question is how to make sure that that other package would be
> present whenever a non-systemd init system is in use, and that seems
> like a simple matter of adding dependencies from the
> set-foo-as-active-init-system package for foo.

Yeah, that was my thought.  It also keeps the infrastructure for
supporting other init systems in its own packages maintained by people who
use those init systems, which seems likely to improve the quality of
maintenance and shorten the loop on bug fixes.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>