Author: Isaac Dunham Date: To: Anto CC: dng Subject: Re: [Dng] Which package generates /lib/systemd and /etc/systemd
files?
On Tue, May 05, 2015 at 08:44:22PM +0200, Anto wrote: >
> On 05/05/15 18:52, Noel Torres wrote:
> >
> >As a resume: If you want a systemd-free system, Devuan is your
> >distribution, and will always be. But if you want a system designed to be
> >unable to run systemd, please leave us. This is not the place for such an
> >anti-freedom POV. > Do you understand the impact on what you wrote?
>
> How much efforts will that be to support systemd *without* any locked-in? I
> believe this is what you meant, because Devuan will be exactly the same as
> Debian if the support for systemd would also force the locked-in of a lot of
> packages. And unless the number of Devuan developers will be as many as
> Debian developers, I think you are just dreaming.
I think an overview of the different levels of systemd dependency
is in order to clarify what's under discussion.
Level 0:
On paper, systemd can boot a system even if everything else is
completely unaware of it. (This was an important part of how it got
anywhere to begin with.)
This gives almost exactly the same functionality as sysvinit, since
it uses init scripts.
Level 1:
If someone wants to use the dependency resolution that systemd has,
they need to have a configuration file for the software that specifies
how to start it and what needs to happen first.
Level 2:
The systemd maintainers claim that writing applications to use systemd
"gives the users a better experience" or some such garbage; this usually
means a run-time dependency on libsystemd. Such software usually can
still run if systemd is not PID 1.
Level 3:
A few programs require a DBUS method or similar thing tht must be
provided by systemd at runtime.
It's settled that we don't want *anything* to be at level 2 or higher
integration.
Now, what's under discussion is whether we are OK with *not* rebuilding
packages that are at level 1.
This does not mean adding systemd to the repository, it does not require
supporting systemd, it does not mean that we add service files to
anything: all that it means is we decide that we can ignore configuration
files, when there's no dependency.
Remember: a configuration file can be modified as the user wishes, or
even deleted, and the package manager will respect the user changes.
I read Noel's comments as being in favor of leaving whatever is at
integration level 1 alone, so that *if* someone decides that *they*
want to install systemd on their system, we don't make it harder
than necessary. This does not require that *we* should test it, just
let things remain (without any support from us).
I'd think that this is OK, apart from the question of whether all
packages can be rebuilt on a Devuan system.