Re: software suites (was: Adding own Software?)
On Tue, Aug 16, 2005 at 11:47:30AM +1000, Vincent McIntyre wrote:
> > > 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.
when you say "this kind of software", I read: "poorly written".
Sorry, but that is a popular stereotype of scientific software
packages.
> I'm talking here about largeish software packages, which have a lot
Large, oftentimes, because they don't use shared libraries, because
they were written before shared object facilities were widely
implemented, and haven't been updated since. Such software packages
could easily be a fraction of the size.
> 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.
Thats not a big problem at all; if a task makes assumptions about its
environment, and isn't readily callable from a /usr/bin/sh, then put
in in /usr/lib/pkg/, and /usr/share/pkg/ for data, of course.
> 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 is bad because I presently have >1000 packages installed, and I
really don't want a 50k path. Software *can* be made to conform, in a
good way, to meet users' expectations, and to Do What I Mean. Debian
has 10k packages, and if one of the packages wants to stand out in
/opt/usr/local/, then its just an indication that its going to be a
headache.
> 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?
Yes, the FHS dictates that exactly the following exists in /usr/:
X11R6 bin doc games include lib local sbin share src
Okay, so some existing software (mingw32) breaks it, but its a known
problem, and its only waiting on a generalized longterm fix
(multiarch, I think).
X11R6/ is there for historic reasons only, share/ is sharable by NFS
(or other) to machines of arbitrary arch running the same distro, and
src/linux/ is not where you put your freshly downloaded kernel for
compilation.
> 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.
I've not used it either, but if it uses /usr/{lib,share}/octave, then
it sounds nice.
> For this case, it might be helpful to have a clear (& brief) statement
> of what a FHS-compliant suite should look like when packaged.
I think the FHS is precisely this, no? "Scientific" software is just
software.
Greetings,
Justin
Reply to: