Michel Schinz <Michel.Schinz@ep...> writes:
> So, as I promised, here is my first draft of a document describing the
> packaging of libraries for scsh. A few notes about it:
Great! This proposal does not address the issue of cramming all the
packages into the first line of the script, but it seems like a solid
step in the right direction. It initiates a discipline for
contributing packages to scsh other than putting them in the language,
and the discipline itself is the important thing -- our community is
currently so small that the details of that discipline can completely
change if necessary after we have a little experience.
> 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. It might be useful for packages to include some
metadata so that repositories or tools can generate such
hierarchies. This is probably not a first order concern.
> [This organisation has unfortunately a drawback: it is not really
> compatible with tools which look up documentation in a given set
> of directories. For example, "man" looks in a set of directories
> for documentation, given by the MANPATH environment variable.
> This variable would have to be augmented each time a package is
> installed, which is not easy to do. I don't think this is a real
> problem, as "man" might not be the format of choice these days.]
Operating system specific installations (.deb, .rpm) can deal with
these issues by creating and removing the necessary links to comply
with each operating system's standards.
> - For every package installed, there is exactly one symbolic link
> in the "active" directory. The link has the name of the package
> and points to a specific version directory of the package, which
> is the "active" one, i.e. the one to use by default.
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
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.
> * Automatic management of packages
>
> Ultimately, a tool to automate the management of packages could be nice
> to have. Such a tool would make it possible to download, install,
> update, list and remove packages.
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.
In reality, the two systems will have to work side-by-side, probably
the operating system native tool would work in /usr/.. and the scsh
native would work in /usr/local/... .
> 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?
Good work, I hope these suggestions are useful. Let's make this first
step, and tackle the unresolved issues again later.
--
Anthony Carrico
|