On Fri, Jul 27, 2018 at 11:37:57AM +0200, Dr. Nikolaus Klepp wrote:
> Am Freitag, 27. Juli 2018 schrieb KatolaZ:
> > On Fri, Jul 27, 2018 at 12:05:54AM +0200, Dr. Nikolaus Klepp wrote:
> > > Sorry, this may break the thread but I already deleted the original message.
> > >
> > > To make things short: this a minimal "libnosystemd" for sshd on ascii. It basicly does nothing at all. To be more specific, it does exactly the same that libsystemd0 does, which is nothing.
> > >
> > > Unpack where you like, compile and copy the resulting library to /lib/x86_64-linux-gnu/libsystemd.so.0.17.0 (it might be a good idea to backup the original). "service ssh stop; service ssh start" and oh magic sshd is up and running without libsystemd0 - that is all it does. Good enough for me as a proof of concept :-)
> > >
> > > Nik
> >
> > It's not that easy since already understanding how to build libsystemd
> > alone and what should be nooped is not a trivial task (at least for
> > me). Especially because they have recently abandoned autotools for
> > ninja.
>
> 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.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]