scsh-hackers
[Top] [All Lists]

Re: [Scsh-hackers] packaging proposal design issues

To: Anthony Carrico <acarrico@memebeam.org>
Subject: Re: [Scsh-hackers] packaging proposal design issues
From: Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de>
Date: Fri Dec 5 02:51:02 2003
Cc: Michel Schinz <Michel.Schinz@epfl.ch>, scsh-hackers <scsh-hackers@lists.sourceforge.net>
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Anthony Carrico <acarrico@memebeam.org> writes:

>> 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).

We need the option to skip installation of the shared parts for the
current version of the proposal, too.

[snip]
>> 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.

I don't think taking care of S48 right now is worthwhile. It just
lacks too many required features such as command line options for
loading exec scripts, or a library path. The fact that scsh is
currently not based on the most recent version of S48 compilcates this
further.

--
Martin


<Prev in Thread] Current Thread [Next in Thread>