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.