If anything, shims for systemd should be something that relies on
LD_PRELOAD to provide the wrappers, rather than making them broadly
available - so that it's possible to use it as a workaround, but without
deliberately doing so, the affected packages WILL break.

I fear however that we're going to see packages with deeper and deeper
entanglement with systemd, where it won't be a simple matter to patch the
software to work correctly. Gnome already seems to be moving full speed
ahead in this direction, and unfortunately, it's a matter of time before
others follow suit. Since systemd is firmly committed to being Linux only,
other *nix operating systems, including the *BSD world are having to build
workarounds. I think collaboration with them on a common implementation
that provides a workable, portable, and non-invasive comparability layer
would be mutually beneficial, and needn't be exclusive of efforts to
disentangle packages from the systemd beast altogether.


On Fri, Aug 14, 2015 at 8:59 AM Simon Hobson <linux@???> wrote:

> > It seems to me that it's good to have shim programs that satisfy
> > dependencies of apps on systemd, each shim performing some systemd
> > function. Here's why:
> >
> > Suppose there are 10,000 application programs (apps) for Linux,
> > and their developers foolishly insert dependencies on systemd.
> >
> > If Devuan developers write 50 simple shims to fulfill those
> > dependencies, then Devuan users can run those 10,000 apps
> > as they are, directly from the Debian repos. And when the
> > apps are updated, they will still run.
>
> As pointed out already, unless the systemd calls are not actually doing
> anything useful to the operation of the program then replacing each call
> with a "null operation" will break the program.
>
> But, IMO there is a more important philosophical reason not to do it.
>
> If it were technically possible to create all these shims that would "do
> nothing but magically still let programs work", by doing it that way you
> have "legitimised" the use of those systemd calls. As in, "use as many as
> you like, it doesn't actually matter".
> If Devuan can get to the point where the devs that are "blindly going down
> the systemd alley"* want to get on board, without these shims there is a
> clear message - fix your code or it can't be installed.
>
> * I'm sure some feel they are using systemd calls for a good reason. In
> many cases there may well be merit in using them when available.
>
>
> As an example, I tried to upgrade one of my Wheezy systems to Jessie with
> *systemd* pinned as not installable. It took a bit of messing around
> figuring out what the broken dependencies were, and in the end I only had
> ONE single package that I needed and which wouldn't install - clamav-daemon
> (the other clamav* packages were fine, just not that individual one). In
> response to my messages on the clamav mailing list and bug report, it turns
> out that they only make ONE call to libsystemd during startup and then
> never use it again, and it's not even an essential call - but no, it would
> be a "waste of CPU cycles" to do a "if exists libsystemd0 then call ..." I
> assume it's not considered a waste of cycles to maintain a separate package
> for Wheezy security updates !
> If you provide a shim, then you legitimise this sort of behaviour. Which
> would you prefer : a clamav-daemon package with a dependency on a "fake"
> libsystemd0, or a clamav-daemon package without any systemd dependency ? If
> you legitimise using shims, then the same people that see no reason to not
> hard-depend on libsystemd0 will bring you a package with a hard-depends on
> fake-libsystemd0.
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>