[Arm-netbook] systemd dependencies (was Re: new development laptop needed, looking at dell xps 13 9350)

[Paul Boddie]

On Thursday 8. December 2016 16.00.56 Julie Marchant wrote:
> On 12/08/2016 09:25 AM, Paul Boddie wrote:
> > I don't want to get into an argument about systemd, but one way of
> > detecting systemd would to be for things to test for a file that always
> > gets installed as part of the systemd packages. This file could even
> > have zero content and be explicitly added by the package maintainers (if
> > the systemd people kept renaming everything), and nothing would ever
> > need to link to anything. You could call this magic file libsystemd.so
> > if you wanted, and it could actually be libsystemd.so if you really
> > wanted. That would be a very Unix-like way of dealing with this.
> 
> That would not be a portable way to do it. Very bad idea. What if the
> system you're on uses that directory for something else? It could be
> that it just has to not support systemd at all. Or what if that turns
> out to be the file name of something else? You can make this unlikely,
> but not impossible.

We're talking about distributions where the package maintainers get to decide 
where everything lives. So, if the systemd packages were installed and 
configured, there would be a file indicating that systemd is available. 
Indeed, the Debian configuration mechanisms may well be able to provide such 
information anyway, so an alternative could involve running one of the Debian 
tools to determine what the init system is. Obviously, I'm only talking about 
Debian here: other distributions would have their own mechanisms.

It would be distribution policy to not let such files be populated by other 
packages. When people advocate abandoning distribution tools and using all the 
different language- and system-specific tools for distributing software 
instead, they often overlook the value provided by things like distribution 
policies, whose aims are to make sure that everything works together. The 
approach described above relies on Debian policy and tools to have a chance of 
working. Similar caveats apply to other distributions.

> And how would it be Unix-like? OK, I'm much younger than Unix and only a
> video game programmer who mostly uses Python, so maybe this is just
> because of that, but I have never heard of any Unix-like system telling
> programs about its capabilities by having or not having a particular
> file. Usually you use a simple function for that. Checking for the
> existence of a particular file would be esoteric.

I'm also younger than Unix. :-)

What form would this "simple function" take? If it is a Python function, it 
has to be implemented by a module which in turn needs implementing using a 
file. Similarly, a C function would need to be implemented in a library which 
in turn needs implementing using a file. All I'm saying is that demanding a 
specific link dependency is needless overengineering when a well-managed 
system could just permit a test for a file instead.

Not everything is written in languages that like to link to random shared 
libraries: doing things in shell scripts is often sufficient, hence my remarks 
about the absurdity of shared libraries being the point of integration when an 
actual executable (for example, xdg-open) is the better choice. (I seem to 
remember people actually saying that if you wanted to use their special 
libdesktopopen thing from a shell script, you'd need to write a one-off C 
program to link to it yourself, reproducing an executable that they didn't 
want to see provided themselves.)

And the use of files to direct behaviour is definitely Unix-like, directing 
the evolution of Unix-inspired systems like Plan 9, even though they haven't 
proven as popular (but in many respects that has little to do with the chosen 
paradigm itself). Things like the system/device filesystems provided by Linux 
are definitely inspired by this supposed Unix tradition.

> Of course, that's all assuming you don't need to link to libsystemd,
> since that's something you decide at compile-time, not at runtime. If
> you need to link to libsystemd anyway, then the whole idea is pointless.

I thought the issue was that a load of packages had unconditional libsystemd 
dependencies because they might need to test for systemd. Of course, if they 
want to use systemd, they'll need libsystemd, but otherwise they appear to be 
burdened with a chunk of functionality that they might only want to test for.

I don't see generic mail handling programs having unconditional dependencies 
on, say, postfix just to test whether postfix is running (example [*]), so why 
one would need such a specific dependency in the case of systemd is rather 
mysterious. Then again, I haven't followed all the politics around this.

[*] https://packages.debian.org/jessie/mailagent

Apologies if people don't want to read this, but I'm only pointing out the 
apparent absurdity that seems to have led to the creation of Devuan. And 
although it isn't directly related to Luke's current engineering efforts, I 
think that work done for Devuan might help the development of FSF-
endorsed/libre distributions which definitely have been relevant to Luke's 
broader efforts.

But I'll gladly discuss this off-list, particularly with anyone wanting to 
look into doing work on libre distributions.

Paul

P.S. It is interesting to see that you - Julie - have successfully crowdfunded 
software development on Crowd Supply, and I hope that more of this kind of 
thing happens in future.