Am Freitag, 27. Juli 2018 schrieb KatolaZ:
> On Fri, Jul 27, 2018 at 11:37:57AM +0200, Dr. Nikolaus Klepp wrote:
> [...]
> > Well, yes, but the wole point of removing libsystemd0 would be to get rid of anything systemd, not to magle the systemd sources to do nothing (which would be a futile efford). SSHD is happy with "sd_notify", cups needs "sd_listen_fds", "sd_journal_print", "sd_journal_printv", "sd_journal_send" but is happy with dummy functions. Xorg wants only "sd_listen_fds" ... and so on. Virtualy all binaries on my system are happy with just a hand full of systemd functions.
>
>
> I must admit I am lost :)
>
> The whole point of having a nooped version of libsystemd0 is to *not*
> have anything systemd at all running in your system (unless you are
> also scared of the function signatures defined by the systemd crew,
> since those are basically the only piece of code that would remain
> from the original systemd code in a nooped library...).
>
> The alternative is to fork any package that links libsystemd0, remove
> the dependenc *if at all possible*, and *keep it updated with
> upstream*, which means also removing any further dependencies, and
> keeping track of all the patches included by the corresponding Debian
> maintainer.
>
> We have tried the latter alternative first, and it does not work very
> well, unless you have a relatively large number of *maintainers*. I
> need to specify here that a *maintainer* is a person who follows the
> changes happening upstream to the packages he/she is maintaining on a
> daily basis, and rebuilds those packages as necessary, keeping them
> updated. And commits herself to do so at least for an entire release
> cycle.
>
> Unfortunately, most of the great people that helped stripping
> libsystemd deps in Jessie, just disappeared soon after (also due to
> the relatively steep learning curve of the Devuan building pipeline,
> which has been lately somehow simplified by d1h and other tools).
>
> This is not maintaining a package, and this is not helping Devuan in
> the long run. It's relatively easy to strip the deps in a single
> package, and then abandon it in the hope that "others" will take care
> of it in future releases. Almost anybody can do that. The real burden
> is committing to maintaining those changes at least for an entire
> release cycle, better if more than that. That's what a *maintainer*
> should do.
>
> If we don't have enough maintainers, we'll do without, and a nooped
> version of libsystemd looks pretty much like the path of least
> resistance, having the greatest impact with a relatively smaller
> effort.

Ok, here's the part that I do not understand: Why nooping libsystemd (and try to understand that mess) instead of building a minimal (functionless) dummy? There are just a handful of programs (like elogind) that make extensive use of libsystemd and need extra care. The other stuff just uses a minimal set of functions - most just for logging.

nik



--
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...