[Arm-netbook] systemd dependencies (was Re: new development laptop needed, looking at dell xps 13 9350)
paul at boddie.org.uk
Thu Dec 8 17:39:33 GMT 2016
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.
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
But I'll gladly discuss this off-list, particularly with anyone wanting to
look into doing work on libre distributions.
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.
More information about the arm-netbook