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 <li...@thehobsons.co.uk> 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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
