Le 4 déc. 03, à 07:09, Anthony Carrico a écrit :
[...]
As you said in the original proposal:
(This relies on the fact that both the "active" and the "installed"
directory are in scsh's library directories).
I think there is some advantage to getting rid of this redundancy. It
seems a little cleaner, and maybe there would be some performance
advantage, since the search list will be half as long.
Ok. Just for the sake of completeness, I'd like to point out that even
with my original proposal, a user who only uses the default (active)
version of all scsh packages can live with just the "active"
directory(ies) in his scsh library search path.
As far as performance is concerned, if all "active" directories are put
in front of all "installed" directories, then performance would only be
lower with my solution when a non-active version of a package would be
used. I assume this to be pretty rare.
But anyway, as I said, I don't really care and your proposal is fine
too. I guess we'll vote on that just to make sure that nobody is
strongly attached to one solution or the other.
[...]
If I understand Michael's point, he means that if you don't use /usr,
then my proposed tree all ends up in a single directory as you like --
does this constitute "a solution which accommodates both uses"?
It could, yes. What you basically propose, if I understood you well, is
that we use a little FHS-compatible hierarchy for each packages. Then,
packaging systems like Debian would root this little hierarchy directly
in /usr, while users installing the package "by hand" would root it in
a stow directory (to use GNU Stow's terminology).
The installation procedure would still need to differentiate the two
kinds of installation, in order to put symbolic links at the
appropriate place. To illustrate this, let's take an example where we
have two packages, "foo" v1.0 and "bar" v2.0 installed.
With the hierarchy rooted in "/usr", things would look like in your
original message in this thread (I'll concentrate on the pure Scheme
part of packages for now):
/usr/
share/
scsh/
modules/
foo-1.0/
foo.scm
load.scm
foo -> foo-1.0
bar-2.0
bar.scm
load.scm
bar -> bar-2.0
Now, when rooting each package in its own stow directory, we cannot
just use the exact same scheme as above, as we would obtain this (I'll
admit that /usr/local/lib/scsh/modules contains the stow directories):
/usr/local/scsh/modules/
foo-1.0/ (foo v1.0's stow directory)
share/
scsh/
modules/
foo-1.0/
foo.scm
load.scm
foo -> foo-1.0
bar-2.0/ (bar v2.0's stow directory)
share/
scsh/
modules/
bar-2.0/
bar.scm
load.scm
bar -> bar-2.0
And we wouldn't know what value to give to SCSH_LIB_DIRS, unless we
want to include one path per installed package, but we don't want that.
Of course, we could use GNU Stow (or something similar) to solve the
problem, but I hope we agree that's not a good idea. So the
installation procedure should be aware of the fact that it's installing
in a stow directory, and create appropriate symbolic links, to get
something like:
/usr/local/lib/scsh/modules/
packages/
foo-1.0 -> ../foo-1.0/share/scsh/modules/foo-1.0
foo -> foo-1.0
bar-2.0 -> ../bar-2.0/share/scsh/modules/bar-2.0
bar -> bar-2.0
foo-1.0/ (foo v1.0's stow directory)
share/
scsh/
modules/
foo-1.0/
foo.scm
load.scm
bar-2.0/ (bar v2.0's stow directory)
share/
scsh/
modules/
bar-2.0/
bar.scm
load.scm
And now SCSH_LIB_DIRS can be set to
/usr/local/lib/scsh/modules/packages (the "packages" name is not good
but I can't think of something else right now).
One question that remains unanswered is what to do with shared
libraries. In your proposal, you don't put them in a platform-specific
directory, assuming that "lib" is not shared by different
architectures. I don't think this is a realistic assumption when
installing in stow directories, but I might miss something, it's
getting late. I'd be interested in knowing how people who install
software for several platforms and use the "stow" idea, organise this.
At work we have only one architecture, so I don't have experience with
that.
Anyway, that's one solution. The only thing I dislike about it is the
really deep hierarchies it creates when installing in stow directories.
The only way I can think to avoid them is to do as I suggested in the
previous message, and have (slightly) different layouts depending on
whether everything is installed in a common hierarchy, or whether every
package gets its own.
I just want to quickly say something about this solution, as I think
that it's not as complicated as it sounds. Basically, what the
installation procedure needs to know is where to put the different
kinds of data, like:
- documentation,
- Scheme code,
- shared libraries,
- etc.
We could imagine that the installation library provides functions to
get the name of each of these directories, in addition to functions to
install files in any of these directories as I suggested yesterday. So
we would have functions like:
(install-file <source-file> <location> [<relative-dir>] [<perms>])
(get-directory-name <location> <staging?>)
where <location> could be a symbol specifying which kind of directory
is meant, chosen among "documentation", "scheme-code",
"shared-libraries", and so on. "relative-dir" would be relative to the
location in question.
Now, a call like
(install-file "index.html" 'documentation "html")
would install "index.html" to
"/usr/share/doc/scsh/modules/foo-1.0/html/index.html" when performing a
"scattered" installation, and in
"/usr/local/lib/scsh/modules/foo-1.0/doc/html/index.html" when
performing a "stow-like" installation.
Likewise, "get-directory-name" would return something different
depending on the installation kind. I think you get the idea. The
"staging?" parameter, a boolean, specifies whether we want the location
in the staging directory (in which the files are originally copied) or
the final installation directory. (Right now, the installation library
has two functions for that, "package-installation-dir" and
"package-installation-staging-dir").
That's pretty much all that would need to be changed, from the point of
view of the clients of the installation library. And the implementation
of the installation library would not be a lot more complicated, I
guess.
I hope I've presented both your ideas and mines clearly. We'll have to
vote once more about all that soon I guess, but I would first like to
be sure that the different ideas and their implications are well
understood by everybody.
Ah, and something I'd also like to discuss is whether we should have
separate hierarchies for "s48" and "scsh" or not. But not right now.
Michel.
|