<div dir="ltr"><div class="gmail_default" style="font-size:small">The question of dependencies came up recently in a bug:<br></div><div class="gmail_default" style="font-size:small"><br><a href="https://bugs.freedesktop.org/show_bug.cgi?id=26085">https://bugs.freedesktop.org/show_bug.cgi?id=26085</a><br clear="all"></div><br><div class="gmail_default" style="font-size:small">​Like any project that aims to be portable, xdg-utils needs to be careful about the dependencies it assumes. However, this should be balanced against both the ability to implement functionality in a good way, and developer time.<br><br>Further, I think it's reasonable for modern free software to assume that most users will be able to install it from some sort of packaging system, even on OSes that do not come with such as system (I mean principally Mac OS X; the Portland project only includes UNIX-like OSes, so it's reasonable not to worry about MS Windows). As free software authors, it doesn't make sense to limit the functionality of our programs or give ourselves more work just to make our code work on proprietary systems, especially when those features can for the most part be easily installed.<br><br></div><div class="gmail_default" style="font-size:small">In the past, when it was common to build code from source, one worried about the number of dependencies. Now, I think that is unnecessary; rather, one should worry about the quality of a given dependency. In particular, how mature is it (in other words, how often will updates break our code?), how portable is it (how many systems does it work on?) and how widely packaged is it (how many users will have to install it from source?). When a dependency helps us write our program, is portable, mature, and widely packaged, it should be easy to adopt it, all other things being equal; for example, it makes little sense to use multiple dependencies to perform the same task.<br><br></div><div class="gmail_default" style="font-size:small">This is particularly important for xdg-utils, for two reasons:<br><br></div><div class="gmail_default" style="font-size:small">1. It interfaces to a lot of system-dependent facilities. Hence it is forced to rely on a wide variety of prgorams, although only a few may be needed for each particular xdg-utils script and desktop environment.<br><br></div><div class="gmail_default" style="font-size:small">2. xdg-utils is usually installed as part of an environment (the scripts are of little use on their own), so the argument for assuming a packaging system is even stronger.<br><br></div><div class="gmail_default" style="font-size:small">In the case of the bug I mentioned above, I used a shorter form of the above argument to argue that it is OK to rely on Perl. Perl is installed by default as part of pretty much every desktop environment these days, it's stable from one version to another (these days, most new Perl 5 features must be explicitly activated), and it runs on every OS the Portland Project targets.<br><br></div><div class="gmail_default" style="font-size:small">(What is less clear in this case is whether it's OK to rely on a non-core Perl module; that might need further analysis for this particular issue.)<br><br></div><div class="gmail_default" style="font-size:small">I'd also suggest that it's worth thinking hard about dependencies for two other reasons:<br><br></div><div class="gmail_default" style="font-size:small">1. The current implementation of many scripts as shell scripts results in serious problems. First, I think no-one would disagree that POSIX shell is simply a horrible language. Secondly, we have one potentially serious security bug open, and shell makes it almost impossible in general to guard against quoting bugs. So we should at least consider allowing another language. I'll address this question in a postscript.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2. xdg-utils has a structural problem: it tries to support a huge range of desktop environments all by itself. This is not good for the maintainers of xdg-utils, nor for the maintainers of those DEs, who can't directly fix problems that affect their particular environment; and it also annoys developers of programs that rely on xdg-utils, when they get bug reports for desktop environments they don't use for xdg-utils which they can't easily fix. For example, just google "vlc xdg-screensaver", and see the VLC developers get seriously irate with xdg-screensaver; I'm not saying they're justified, but one can hardly blame them. I suggest that xdg-utils needs to allow at least desktop environments the ability to substitute their own "back ends", and that means using whatever dependencies they see fit. At that point, the dependencies for a given DE are no longer our problem.<br><br></div><div class="gmail_default" style="font-size:small">Thanks for reading. Stop now unless you are interested in language choice.<br><br></div><div class="gmail_default" style="font-size:small">Reuben<br><br></div><div class="gmail_default" style="font-size:small">P.S. For a second language: I suggest that there are really only 3 sensible choices for languages that are sufficiently familiar, portable, stable and widely-packaged: C, Perl and Python 2. C is ubiquitous, but worse to write than shell in some ways (better in others); I do not seriously entertain it as I don't think it would be a definite improvement, and it would also require a build system, i.e. a whole other world of pain. Python 2 is good and stable, but not always installed by default: on some systems it is simply not part of the default set of packages; others have moved to Python 3 as the default; it in turn is less stable and less widely-installed than Python 2.<br><br>That leaves Perl. I'm no fan of Perl (I'd much rather write in Python), but Perl 5 is installed by default on just about every modern UNIX-like system, and it is a big improvement on shell. Therefore I'd suggest allowing its use, and in some cases rewriting code in it. It would even solve some portability problems that shell has, for example, the temptation to use non-portable options to standard POSIX commands, as seen in <a href="https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64634">https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64634</a><br></div><div class="gmail_default" style="font-size:small"><br></div>-- <br><div class="gmail_signature"><a href="http://rrt.sc3d.org">http://rrt.sc3d.org</a></div>
</div>