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)?
> 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.
Unless you're anticipating that the installation procedure would
compile for all the architectures in one pass, or something like that,
then I guess we just need an option to specify (or to tell install to
guess) the architecture specific version of "lib", but if anyone was
going to use this option, then in reality they would probably also
want an option to skip the installation of the shared parts (since it
would only be necessary on the first platform).
> Anyway, that's one solution. The only thing I dislike about it is the
> really deep hierarchies it creates when installing in stow directories.
That is a fair criticism.
> 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 think that avoiding deep hierarchies isn't worth burdening the user
code with different layouts for finding libraries and other resources,
but I respect the fact that this flexibility would never leave a
system administrator with special needs out in the cold.
This reminds me: in order to locate resources, we still need to
provide a method for packages to find their root (in the single layout
option) or both their root and their layout (in the custom layouts
option).
> 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.
Right on; it is actually so simple that it is usually accomplished
with a few variable substitutions in a Makefile.
> I hope I've presented both your ideas and mines clearly.
Yes, it looks very good. Thank you!
> 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.
Thanks. Maybe today it only impacts on sunterlib.
--
Anthony Carrico
|