Re: Bug#886238: Please introduce official nosystemd build profile
- Date: Wed, 03 Jan 2018 20:12:25 -0800
- From: Russ Allbery <rra@xxxxxxxxxx>
- Subject: Re: Bug#886238: Please introduce official nosystemd build profile
Adam Borowski <kilobyte@xxxxxxxxxx> writes:
> -shim is moribund (and never worked right even when it was maintained),
> thus installing it on systems with modular inits is damage. I believe
> this is the problem that should be solved first -- because all
> non-trivial cases mentioned above use logind or an equivalent, and to
> implement a profile you need to know what alternate dependency to use.
> The name I hear the most is elogind, but other options also get
> mentioned. It'd be good if someone more knowledgeable could say more; I
> think multiple Debian derivatives are experimenting here.
> Once such a solution is chosen, implemented and tested, only then it'll
> be time to fix dependencies -- inside Debian rather than some
I think this would be great. It's both meaningful and useful in creating
more ecosystem diversity. I'd be happy to take patches for this sort of
thing as a maintainer, and I think it's a much better use of people's
energy and good will.
I think the key to a good path forward is to recognize that systemd solved
some specific problems, and to build a roadmap of which problems do indeed
need to be solved and the alternate solutions to them, and which aren't
important enough to folks who don't like systemd to solve and therefore
will stay systemd-exclusive features until that changes. Then there can
be a sustained ecosystem, with a clear mission, alongside systemd, and
Debian can endeavor to support both.
And the resulting tools, assuming they're built in the small pluggable
tool model (seems like a likely bet) would be broadly useful even for
those of us who like systemd. For example, I'd love something that can do
the jailing and seccomp rule configuration that systemd can do, with the
same or very similar syntax and, particularly, the syscall groupings, but
that is implemented as a standalone wrapper program that I can use in
situations where I don't want to spawn a service.
Russ Allbery (rra@xxxxxxxxxx) <http://www.eyrie.org/~eagle/>