Michel Schinz <Michel.Schinz@epfl.ch> writes:
> Anthony Carrico <acarrico@memebeam.org> writes:
>
>> On Thu, Dec 04, 2003 at 11:09:25PM +0100, Michel Schinz wrote:
>>> 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:
>>
>> I don't have any experience with this style administration, but
>> wouldn't anyone using that kind of a policy already have their own
>> local means of dealing with those symbolic links (stow itself, Michael
>> Sperber's "two scsh scripts", or whatever)?
>
> Yes, for sure. It's just that these techniques are pretty heavyweight,
> since they imply an additional step in the installation procedure, and
> they "load" the file system with many links, most of which are
> unnecessary. In the case of scsh packages, the only links which are
> really necessary are the ones which enable scsh to find its Scheme
> code.
>
> That's my main motivation for having two layouts. I'd like to have
> something which looks good and is easy to use for both kinds of
> installation.
I'm definitely not an expert when it comes to installation
hierarchies, but wouldn't it be possible to provide the installation
script with a couple of options for the target directories of
documentation, machine-dependent files and scheme code to enable for
example a Debain maintainer to build a Debian package from a scsh
package by calling the installation script with values suitable for
Debian. The Debian package would probably also add a link into the
library path. Of course, this requires a little bit more work for the
Debian maintainer but we wouldn't have to anticipate all possible ways
to install a package.
--
Martin
|