Anthony Carrico <acarrico@memebeam.org> writes:
[...]
> NOTES:
>
> 1. NEGATIVE -- everything is not in one hierarchy. I think this was an
> original design goal, and it is lost. This breaks Michel's idea for
> uninstallation (delete a single subtree). If this goal can't be
> sacrificed, then one way to achive it would be to severely restrict
> the proposal to deal with scheme source code only. My personal view is
> that this design goal is not practical in the Unix context.
Like Mike pointed out, it is indeed very practical in the Unix
context, with the help of symbolic links.
We use such an organisation at work, where we install all software
packages in their own little hierarchy. For example, scsh 0.6.5 is
installed in a directory called "/home/linuxsoft/apps/scsh-0.6.5".
Then we have a link called "scsh" in "/home/linuxsoft/apps" which
points to the active version of scsh, say 0.6.5. Finally, we have
symbolic links which provide the traditional "flat" Unix view. The
directory "/home/linuxsoft/bin" contains symbolic links (and only
symbolic links) to all the actual binaries stored in the little
hierarchies mentioned above. It's that directory that people add to
their $PATH. And we have similar directories of links for "man",
"share", etc.
This way of managing software is not new, see for example GNU Stow
which creates all these links automatically [1]. I also found recently
an article discussing this very same idea in the context of NetBSD
[2], which you might find interesting.
As far as I'm concerned I use a scsh script which does things slightly
differently than stow, but the basic idea is the same. Notice that I
also use this scheme on my home machine, even though a packaging
system (Fink) is available for it. That's because sometimes the
packaging system isn't usable, for example when you want to install a
release candidate of some software to test it, for which a package is
usually not available; or when you want to have several versions of a
package installed, which typical packaging systems do not support.
[1] http://www.gnu.org/software/stow/
[2] http://www.bsdunix.ch/public/eurobsdconf/crooks.ps
> 2. POSITIVE -- multiple architectures. The problem with machine
> dependent files (shared libraries, etc.) is solved. They go in the
> .../lib directories which are not shared among different
> achitectures. The machine independent files (including scheme sources)
> go in the .../share directories; they are shared among machines with
> different architectures.
That would indeed be a positive point.
> 3. POSITIVE -- miscellaneous docs are found in the place that users
> will look for them (../share/doc/...). It is incorrect to store this
> information in .../lib.
To make sure that users find documentation where they use it, one
could simply put symbolic links from share/doc to the doc/
sub-directory of the package directory containing the documentation.
> 4. NEUTRAL-POSITIVE -- Note that still only one symbolic link (foo ->
> foo-1.0) is necessary for the "active" version feature. This design
> does not required programmers to add any extra directory levels when
> using the active version of the script (to load active use:
> foo/load.scm to load versioned use: foo-1.1/load.scm).
Indeed, that's another way of designating the "active" version of a
package (it's in fact the one we use here at work, as explained
above). I originally chose the other one with an "installed" and
"active" directory as I felt that it provided a better "separation of
concerns", so to speak. But I have no strong opinion in its favour.
> 5. BIG-POSITIVE -- Our packages will conform to the FHS. My
> operating system's policy (Debian's) requires this for all packages,
> I'm sure that others do too.
For what it's worth, the Fink policy uses the word "should" and not
"must" like Debian's policy when it comes to conformance with the FHS
[3] (full conformance is anyway not attainable with Fink, since it
doesn't have control over /usr).
[3] http://fink.sourceforge.net/doc/packaging/fslayout.php#fhs
- * -
Anyway, let me try to state more precisely the cause of disagreement,
and the problems presented by both our proposals.
To summarise, I would say that your proposal is nice when some package
management system is available, because it organises files as these
systems expect them to be organised. On the other hand, when no
packaging system is available, or when it cannot be used, your
solution has the standard problem that the files belonging to a
package are scattered around.
My proposal on the other hand works well when you don't have a
packaging system at hand, or cannot use it. But it makes it harder, as
you pointed out, to create "system" packages (e.g. Debian packages)
for scsh packages.
I think we should try to find a solution which accommodates both uses,
because both are common. Packaging systems work well for single
machines, and when the user has root access to it, but as soon as you
have to manage a large network of machines, it is usually far easier
to install software on one central server. This makes most current
packaging systems unusable.
One solution could be to provide an installation library which can
perform the two kinds of installation. The installation script could
be passed an argument to specify which kind of installation to
perform.
More precisely, instead of providing the simple functions provided
now, which simply copy directories or files, we could have functions
to install specific kinds of data. For example, a function
"install-documentation" should be used to install documentation, and
it would put it either in .../share/doc/<pkg>/... or in
<root>/installed/<pkg>/<vers>/doc depending on the kind of
installation the user requested. This would mean more work for us, but
it could be worth it.
Having these specific installation commands could also be useful for
other things. For example, I think that it would be nice if the
installation library could maintain an index of all documentation
available about scsh packages, as an HTML document. This index could
easily be updated by "install-documentation".
What do you (and others) think?
Michel.
|