software suites (was: Adding own Software?)
> > I'm not sure what you think about people contributing their own software
> > or about such a program which is only of use for a small group of users.
>
> There are a lot of programs for a small group of people. Build a package
> for your software and provide it.
>
This prompts me to raise an issue about scientific software, the old
chestnut about where things should be installed. If there is a
widely-sanctioned approach to this which you are aware of, please
contribute a summary or a pointer. But read on a bit before pointing
me to the policy manual.
What I'm hoping to stimulate is a discussion of options and some
recommendations to post on the wiki. There may also be a hole in
Debian policy in relation to this kind of software, if there is
then perhaps we can come up with a patch.
I'm talking here about largeish software packages, which have a lot
of "task" programs that perform specific processing steps (usually
under a lot of assumptions about their runtime environment).
I call them software suites, to keep the distinction from .debs
(what most people here mean by "packages", yes?).
The main problem that suites pose is that the individual tasks usually
have short names that frequently clash with names of existing programs
in /usr/bin. There is also the bsd-ish argument that /usr/bin is for
"system" software that potentially everyone on the system will use,
while a given specialised software suite will be used by only a small
fraction of users. Implicit in my thinking here is that the software
will get installed on multiuser systems, not just systems where there
is one user who has root access and can customise the list of installed
software at will.
A typical solution to this is to install from source tarball, say
to /applic/foo, and temporarily prefix /applic/foo/bin to $PATH.
This works well, but does raise problems if you want to package the
suite to make installation faster and more reliable. This case is
where I'm the most confused about what could be done better.
I'm thinking it might be useful to have a standardised "debian way"
of $PATH-mangling that would be invoked when a given user chooses
to "subscribe" to a package. Where in the filesystem would it be
appropriate to put such "subscribable" software?
One class of suites where this is mostly a solved problem is those
that make the user run all the programs in the suite from inside a
command shell. Two examples of this are IRAF and Octave.
In the IRAF case, there is a command shell and a handful of other programs
that go into /usr/bin, and then a large set of stuff - headers, libraries,
reference data - that goes into /usr/iraf. I gather this breaks FHS?
I've not used octave but from what I can gather it uses a similar
approach - a shell /usr/bin/octave-2.0.17, and then a mountain of stuff
in /usr/{lib,share}/octave.
For this case, it might be helpful to have a clear (& brief) statement
of what a FHS-compliant suite should look like when packaged.
So - opinions, corrections, pointers?
Cheers
Vince
Reply to: