Shiro Kawai <xxxxxx@lava.net> writes:

> From: Derick Eddington <xxxxxx@gmail.com>
> Subject: Re: Please drop the ^main^ thing
> Date: Fri, 25 Sep 2009 11:23:22 -0700
>
>> It's not only for single-component library names.  If you have libraries
>> (acme foo), (acme foo helper1), and (acme foo helper2), you may want
>> them all organized under "acme/foo".
> [...]
>> A collection of libraries with common prefix (acme ---) might have an
>> (acme) library and you may want all the libraries organized under
>> "acme".  I don't know how usual this will be.
>>
>> I've been under the impression there's enough demand for the
>> organize-under-the-same-directory ability of the implicit file name to
>> justify supporting it.  I could be wrong.  Am I?
>
> Just as a data point, I don't have desire to organize a library
> under a single directory.   I don't mind the library tarball
> expands into acme/foo.sls, acme/foo/helper1.sls, acme/foo/helper2.sls...
>
+1. I do my library collection layouts like this, and don't feel a need
for the implicit rule, and would rather have it dropped -- IMO, while it
may be a minor convinience when dealing with library collections, it
also affects negatively the complexity of the proposed SRFI and its
implementations; in a way you could argue that it's not a convinience,
but a burden, as there's an additional rule to keep in mind when dealing
with library collections.

>> Being able to organize all libraries with a shared name prefix under the
>> same directory seems desirable so that, when managing the related
>> libraries, the directory is the single thing for them, instead of having
>> to remember there's also the file outside the directory and also deal
>> with it.  E.g., a collection with (acme) library is distributed in a
>> tar/zip with files all under the "acme" directory, and when you want to
>> move/delete it you only need to remember and deal with the directory.
>
> That sounds plausible, but most of the time I go for some kind of
> install process, for libraries may need some sort of setup depending
> on the environment.  Some libraries needs to install other components
> anyway (e.g. auxiliary helper command).  Then it is safer to rely on
> 'uninstall' make target.
>
> Simple libraries may not need that, but it is a burden to remember
> which ones need to be explicitly uninstalled and which ones are just
> ok to remove single directory.  Since not all libraries are that
> simple, each library needs to provide uninstall instruction anyways; I
> won't rely on my memory and just remove one directory.
>
> (I'm not proposing sophisiticated package managing utility; good old
> make does the job.)
>
FWIW, I'm working on a package management tool for R6RS library
collections, which should eventually handle installation, deinstallation
and dependencies between library collections. It will also give the
library collection maintainer some leeway in how they organize the
directory tree inside the package.

Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>