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. The Devuan devs don't have to deal with those 10,000 updates at all. And the shim programs only have to be updated when the systemd API that they are emulating changes. Now suppose that systemd shims are not used. That means that all 10,000 apps have to be patched by Devuan developers so they don't depend on systemd. And all the 10,000 patched apps have to sit in a Devuan repo that has to be maintained. And every time one of those 10,000 apps is updated, the Devuan devs have to repatch it to remove the systemd dependencies and recompile it. The Devuan devs can request the app devs to remove the systemd dependencies, but that has a low probability of success, because the app devs have lemming-consciousness rather than Unix-consciousness, and think that systemd is fine because the major distros have adopted it. So using a relatively small number of shim programs in Devuan will save an enormous amount of work for the Devuan developers, which will allow them to use their time for more productive purposes -- making Devuan more generally useful and attractive, thereby gaining far more users. Now I realize that the idea of having those shim programs is going to make some Devuan people scream, "Unclean! Unclean!". But the shim programs will be under our control and will save us a huge amount of constantly ongoing work of updating apps. And Devuan will succeed with only 25 developers and administrators instead of needing 500. So please drop the fear of contamination, and consider the shims as a simple, inexpensive and effective wall of defense against systemd. Mark _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
