So, as I promised, here is what I currently have to install package.
It's still pretty preliminary, but the general ideas are here, and I
would be glad to get comments about these.
My current view of the package installation process is the following:
users should be able to install a package by executing a program
called "install" located at the first level of the directory created
by exploding the package archive. This script takes at least one
mandatory argument, "--root", which is used to specify the "package
root" in which the installation should be done.
To help package authors, we provide several files which make it very
easy to write install scripts. These files are:
- "install" an sh script which just launches scsh with the appropriate
arguments, because I know of no other way to do that portably,
- "install-lib.scm" the installation library, which also contains the
main installation function called by the above script,
- "install-pkg.scm" the structure and interface definition of the
installation library.
I attached all these files to this mail.
Apart from these files, the package author has to provide a file
called "pkg-def.scm" which contains the definition of his package.
This file usually consists of a single "define-package" statement,
which gives the name, version and installation procedure for the
package. But it can contain arbitrary Scheme code. For simple
packages, this file is very short. For example, here is the one I
wrote for sunet:
----------------------------------------------------------------------
(define-package "sunet" (2 0)
(install-directories '("doc" "ftpd" "httpd" "lib"))
(install-file "packages.scm"))
----------------------------------------------------------------------
This defines a package called "sunet", whose version is 2.0, and says
that, in order to install it, the directories "doc", "ftpd", "httpd"
and "lib" as well as file "packages.scm" have to be installed in the
package directory ("package.scm" should be called "pkg.scm", but I
wanted the above example to work for the current version of sunet).
This package definition file is loaded by the main function of the
install library, after it has processed the command-line arguments.
All packages defined in the file (typically there's only one) are then
installed by executing the "body" of the various define-package forms.
To see this file in action, download and unarchive sunet-2.0 (the
official distribution). Cd in the created directory, and put all
the files attached below in there. Then create a new file called
"pkg-def.scm" at the same location, and paste the above
"define-package" in it. You should then be able to install sunet
by typing
./install --root /tmp/root
for example. Ideally, /tmp/root should already contain two
sub-directories called "installed" and "active".
install-lib.scm exports several functions which help during package
installation, the most important being:
(install-file <file> [<target-dir>] [<perms>])
Install the given file in TARGET-DIR. TARGET-DIR is specified
relative to the package directory, and defaults to "." (i.e. the
package directory itself). If the target directory does not exist,
it is created along with all its parents, as needed.
(install-files <file-list> [<target-dir>] [<perms>])
Like install-file but for several files, which are specified as a
list.
(install-directory <dir> [<target-dir>] [<perms>])
Install the given directory and all its contents in TARGET-DIR. This
is similar to what install-file does, but for complete directories.
(install-directories <dir-list> [<target-dir>] [<perms>])
Install several directories in one go.
install-lib also exports other functions, for example to get a list
of all installed/active packages, and to compare/convert versions.
They could be useful later, but for now they are not really needed.
I think that all packages should contain copies of the files
"install", "install-lib.scm" and "install-pkg.scm", à la autoconf.
They are small enough, and it makes it very easy for us to change
things in install-lib without worrying too much about breaking
backward compatibility, since a package author decides which version
of install-lib it bundles with his package. This might raise license
issues, but I gladly put my code in the public domain.
I plan to expand install-lib a bit, mostly so that install scripts
accept more arguments. I'm thinking about the following extensions:
--inactive do not activate the package after installing it (that's
actually already implemented)
--dry-run do not do anything, just display what would have been
done,
--user <name/uid> specifies the owner of all installed files,
--group <name/gid> specifies the group owning all the installed
files,
--perms <perms> specifies the permissions to use for all the
installed files (is that a good idea?).
I'm not really sure about the last three. They are not strictly
needed, since the same result can be obtained through "su", "newgrp"
and "umask" commands before launching the script. That's low priority
anyway.
I also plan to add more error-checking code to install-lib.
Thanks in advance for your comments,
Michel.
install
Description: Text document
install-lib.scm
Description: Text document
install-pkg.scm
Description: Text document
|