Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de> writes:
> Michel Schinz <Michel.Schinz@epfl.ch> writes:
[...]
>> 1. we keep the files where they are now, both in sunet's CVS and in
>> sunet's archive, and deal with the problem by writing a relatively
>> complicated installation script which moves things to the correct
>> location and updates (and rename) the "packages.scm" file,
>>
>> 2. we (well, that would be "the sunet developers") change the
>> hierarchy of sunet's CVS to adapt it to the proposal, by moving all
>> directories containing Scheme code to a "scheme" sub-directory,
>>
>> 3. we forget about the idea of putting Scheme code in a "scheme"
>> sub-directory, and find another name for the directory in which to put
>> shared libraries.
>>
>> Solution 1 means that the installation script becomes relatively
>> complex, but solution 2 might even be more painful because of CVS'
>> inability to move files around cleanly. The sunet developers might
>> also feel uneasy about these changes, as the proposal is not stable
>> yet, and therefore other similar changes might arise in the future.
>>
>> I would personally opt for solution 1 or 3, but I'd like to hear the
>> opinions of other people (especially developers of sunet and
>> sunterlib).
>
> I would vote for 2 but I could live with 1. 3 looks ugly to me. For
> sunet we need Mike's and Andreas' agreement, too and I guess we would
> move the files directly in the repository.
That would be great, solution 2 is actually the easiest for me, so I'd
be glad to see it accepted.
> As for 1, I don't think the installation procedure would have to
> update the packages.scm file as it would go to scheme/ to.
Right, I didn't think about the fact that the "load.scm" file could be
very simple, and just load "packages.scm" in the config package. At
first I wanted to turn "packages.scm" into an "exec" script, but
that's not clean. Moving "packages.scm" into the "scheme" directory
makes everything easier and cleaner.
[...]
> I just realized that adding access to the configure parameters would
> work around this problem by tying the value to the one scsh was
> built on.
Indeed, I think that this would make it the best solution.
> So it really looks as if we need some support from scsh right away
> but 0.6.6 will surly take some time to release[1]. For the time
> being we could define an additional library that approximates the
> value using uname.
Ok, I'll try to think about something along these lines.
> Footnotes:
> [1] I didn't expect the release name to become adequate *that fast* ;-]]]
Yep, me neither :-).
Thanks for your answers,
Michel.
|