Anthony Carrico <acarrico@memebeam.org> writes:
> Michel Schinz <Michel.Schinz@ep...> writes:
[...]
>> Additionally, there could be a hierarchy of directories to classify
>> packages by subject. In these directories, links to the actual
>> package files could be stored.
>
> A subject oriented hierarchy doesn't seem important in the
> installation itself.
That was meant to be in the package repository on scsh.net, not on the
final user's machine. But as you say, it's not really a first order
concern.
[...]
> It seems like the "active" tree could be easily folded into the
> "installed" tree by adding a link like:
>
> sunterlib
> |-- 1.0
> |-- 1.1
> |-- 2.0
> `-- active -> 1.1
>
> I think this would be cleaner, but unfortunately:
>
>> -ll <package_name>/pkg.scm
> becomes:
> -ll <package_name>/active/pkg.scm
Indeed, that's why I have these two separate directories in fact. But
it's true that this could be fixed by changing the behaviour of scsh's
options.
> I suggest dealing with this inconvenience in the future by adding a
> switch that knows about these "packages". For example:
>
> -foo <package_name>
> -foo <package_name>/<package_version>
>
> This is more abstract, the system implicitly knows to follow the
> packaging conventions of loading the pkg.scm file or whatever. This
> abstraction might also allow us to change the system more easily
> without breaking user's scripts.
I'm not really convinced that adding knowledge about the organisation
of packages in scsh itself is a good idea: as much as possible I'd
like to use some general mechanism. That is, an option like -ll.
But of course if using a general mechanism makes things a lot harder,
I guess it will be a good idea.
I have another suggestion which goes a bit in your direction: we could
say that "-ll" can also be given the name of a *directory* as
argument. In that case, it would look for a file, say "packages.scm"
in that directory. A bit like HTTP servers look for "index.html" when
the client requests a directory. This would be backward-compatible,
would enable the same syntax as the one you suggest to use a package
(provided the proposed, dual-directory organisation is kept), and be
generally useful.
[...]
> Shouldn't distributors tap into the operating systems' native tools?
> For example, if I distribute my package for Debian, then I expect that
> my users will use "apt" to install it. I expect that the native system
> will also install the dependencies. If this doesn't work, then only
> scsh-geeks will use my application.
Sure. I also wanted to have a separate tool for people who do not
install stuff via a packaging system. But that's definitely not a top
priority.
[...]
>> Some "meta-data" about packages would need to be defined somewhere,
>> like the dependencies among packages.
>
> It seems like this data is already available in the s48 package
> definitions. Isn't there some logical way to integrate these
> systems?
That would be an idea, yes, I'll think about it (I'm not convinced yet
that we have all the information available there, but we'll see).
Thanks for your helpful comments,
Michel.
|