Managing dependencies

[Reuben Thomas]

The question of dependencies came up recently in a bug:

https://bugs.freedesktop.org/show_bug.cgi?id=26085

​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.

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.

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.

This is particularly important for xdg-utils, for two reasons:

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.

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.

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.

(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.)

I'd also suggest that it's worth thinking hard about dependencies for two
other reasons:

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.

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.

Thanks for reading. Stop now unless you are interested in language choice.

Reuben

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.

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
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64634

-- 
http://rrt.sc3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150115/05909313/attachment.html>