:: Re: [Dng] Which package generates /…
Top Page
Delete this message
Reply to this message
Author: Jude Nelson
Date:  
To: Jaret Cantu
CC: dng@lists.dyne.org
Subject: Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?
Hi Jaret,


> It would probably help to have some ground rules on how Devuan handles
> packages which provide systemd support. I know Devuan says "Nope!" when it
> comes to anything that would introduce systemd/init system dependencies,
> but does it ever get more elaborate than that? If it is already in a wiki
> or README on git, I've missed it.
>
> I can think of two ways these dependencies would come up in packages that
> would need to be addressed:
>
> * Configurable systemd support:
>
> All Devuan packages should be configured NOT to depend on systemd,
> whenever possible. This prevents init-system creep. This doesn't stop one
> from using systemd and a package that has potential systemd support (like
> xfce); however, said package on Devuan would not get any of the additional
> benefits from systemd, such as... um, binary logging?
>
> I would recommend against maintaining a separate, systemd-configured
> repository; that would just be mainline Debian.
>
>

I think the plan is to address needless dependencies and lock-in in a more
general way, via the constitution (
https://git.devuan.org/devuan/devuan-project/wikis/DevuanConstitution).
Sections 2.2 and 9.10 are meant to alleviate this problem--not just for
systemd, but for all software package suites that get included.


>
> * Hard systemd requirements:
>
> I believe this is where gnome3 and similar software falls; the project has
> a hard runtime and/or buildtime dependency on systemd. The only way to
> offer these packages on a non-systemd Devuan is to patch out the systemd
> from the source. Fortunately, FreeBSD already has to do this, right? Just
> raid their patches.
>


+1


>
> This can become a maintenance burden, which is why it is cool to have a
> second option on how Devuan can handle these packages: *don't*.
>
>
>
> Now, this handling of systemd-dependent packages still means that systemd
> can be offered, but only as an init. (An init system only be used to
> initialize a system? What madness is this!) And the only way that systemd
> will ever make it onto your system is with an explicit apt-get install
> since no other packages depend on it.
>
> But IMHO, I think it would be wiser to offer uselessd instead of systemd:
>
> http://uselessd.darknedgy.net/



You may be interested to know that uselessd is effectively dead in the
water. The original uselessd author has since given up (
https://forums.darknedgy.net/viewtopic.php?id=4963). Someone else seems to
have taken over, but I haven't heard anything about its subsequent progress
(last repository commit is January 6:
https://bitbucket.org/Tarnyko/uselessd).


>
>
> Thataway, our (e)udev offering would be less muddled. Also, hilarity.
>


Already working on it :)


>
> Besides, going with uselessd instead would make a systemd-ish Devuan
> different than just Debian with poorer systemd integration. It would kinda
> be like libav over ffmpeg; on this distro, systemd would just be considered
> a "deprecated" version of uselessd (what with its text logs and lack of
> gluttony against fellow software projects), even though both projects (in
> both cases) are considered currently active.
>
>

I'm personally not opposed to someone taking up maintenance of uselessd and
packaging it in a way that it conforms to Devuan's constitution :) The
problem is, we'd need to find someone with the time, skill, and willpower
to do it. That person is not me. I barely have enough time to work on
vdev as it is :(

-Jude