Martin Gasbichler <email@example.com> writes:
> Michel Schinz <Michel.Schinz@epfl.ch> writes:
>> 4. Nothing is said about packages which include C code, like
>> scx. That's largely because I don't know much about them, so I would
>> be interested to get comments about the issues encountered with
> For me, the treatment of packages with C code is a very important
> issue. Eric Knauel is writing three interfaces to C libraries (odbc,
> yp and ldap)
Great, I have often needed an LDAP interface for scsh in the past, and
I agree that having a very good way to interface with C libraries is a
must. Reimplementing everything in Scheme is just not realistic.
> and there is currently no decent way of publishing these libraries.
> Mike promised to write a better interface for loading dynamic
> libraries which would be the key for distributing libraries with C
> code but I don't know how long it will take until he gets to it. To
> prevent us from depending on this, I think we should not speak about
> C code now but keep it in mind for later versions of the spec.
Fine. I'll try to think about the issues.
>> A given version of a package is identified by a name which is
>> obtained by concatenating:
>> - the package name,
>> - a hyphen ("-"),
>> - the package version, with components separated by dots (".").
> I guess this name is the thing you later refer to as "full name"?
Yes. I wasn't clear here.
> I think we should limit the possible kinds of archive and
> compression methods.
Ok. I guess that "tar" for archives and "gzip" and "bzip" for
compression methods are enough for now.
>> To help package authors write their installation script, a small
>> library could be provided with scsh. This library should contain
>> functions to install packages according to the scheme proposed
>> here. (That includes functions to get the name of the directory in
>> which scsh packages should reside---what is called the package
>> root below).
> Yes, I think such a library is really needed. However, we should
> start with something simple so it doesn't hamper the release of this
Ok, I'll make an attempt at defining this. I have to say that my
current specification about the installation part is really
incomplete. For one, I guess we need to be able to pass arguments to
the installation script, like the directory in which the files should
be put, otherwise we won't be able to install things in a staging
directory, and this is needed by packaging tools. And this is also
needed for the reason you outline below: a user should be able to have
his/her private "package tree".
I have to say that I do not yet know what to do with packaging systems
like Fink: should a user first install scsh through Fink (or Debian,
...) and then install scsh packages without Fink, or should there be
Fink packages for scsh packages (e.g. a Fink package for sunet)? I'll
have to think a bit about that, and look at how Perl modules are
managed in Fink, Debian and others.
> But with only one directory, you have the problem that an ordinary
> user might not have the permissions to install the packages there. I
> guess we need several "root" directories to permit normal users to
> install their own packages.
Right. I guess that, as I said above, the installation script will
have to take some arguments, and one of them will be the root in which
the package has to be installed.
Which reminds me of the fact that tilde-expansion is not performed on
the paths contained in SCSH_LIB_DIRS:
% SCSH_LIB_DIRS='"~/projects/scsh-packages/root/"' scsh -ll sunet/pkg.scm
Error: Couldn't find library module file
% SCSH_LIB_DIRS='"/home/schinz/projects/scsh-packages/root/"' scsh -ll
Welcome to scsh 0.6.4 (Olin Shivers)
Type ,? for help.
Maybe it would be nice (and helpful for users who need their own
package root) to perform tilde-expansion on all components of
SCSH_LIB_DIRS at scsh startup.
>> - Every package version directory contains one file called "pkg.scm"
>> (maybe "packages.scm" if we want to keep the current practice)
>> which contains the definition of *all* the interfaces and
>> structures which make up the package.
> An alternative would be to require a "load-pkg.scm" file that is to be
> loaded in the exec package and could load the interface and structure
> definitions and in addition execute arbitrary code. I'm not sure if
> the additional power is needed but it's probably more flexible and
> could save the package author from defining one big package file.
Right, that's a good idea. But then it's not compatible with scsh's
-ll option, it seems. (or we need to provide equivalents to -ll and
SCSH_LIB_DIRS that works for the exec package).
>> Some "meta-data" about packages would need to be defined somewhere,
>> like the dependencies among packages.
> Yes, but I don't think we should talk about this for now. We could
> however standardize the set of possible version numbers to make it
> easier to speak about depending on a specific version (range) later.
Yes, I guess if we say that versions are sequences of integers, and
that they are ordered lexicographically, it's enough.
Thanks for your comments. In the following days I'll update my
document and take a few existing packages (sunet, sunterlib, pgscsh)
and try to write a scsh install script for them. That should help me
find out if the above makes sense, and give me an idea of the
functions we should provide in the library I talk about in the
"Package configuration, building, testing and installation" part. I'll
keep you updated about my progress.