Moi!
Martin asked me to comment on the proposed packaging guidelines for scsh
libraries from a packager's point of view. Note that I'm rather scsh
illiterate, but have some background in mostly Debian-related packaging
work. Anyway, here we go:
My main concern is with install-pkg and its accompanying framework being
included in each package. As far as I understand, this code is not
package specific but should rather be copied in from a generic master
file. GNU autotools do it that way eg. for config.guess and config.sub, and
in practise, keeping them up-to-date is a pain in the neck. Consider an
admin who wants to add a new layout, discovers a bug in the installation
routines, or simply wants to extend them. In the proposed scheme, they'd
have to copy over their new version into each package prior to
installation. Now, unlike GNU autotools, you can rely on scsh being
available on any system where a scsh package is to be installed. So I'd
suggest to put all the generic installation code into the scsh
distribution itself and provide an executable, say, install-scsh-pkg
(identical to the proposed install-pkg) alongside the main scsh binary.
For the package itself, the location of pkg-def.scm should be fixed
(rather that the location of install-pkg). You'll probably need a
transition phase for the packaging proposal to become adopted. During
this time, you might either want to ship a separate, small package
containing install-scsh-pkg and friends. Even if you prefer to stick
with the per-package install-pkg approach, please consider defining a
fixed location for pkg-def.scm, as this will allow smooth transitions to
different schemes later on.
It's usually a good idea to include an identifier in files like
pkg-def.scm, indication which version of the packaging proposal they
comply with. Allows you to change your mind later on without causing too
much breakage.
Finally, some of the directories smell like their content might depend
on a specific version of scsh. For instance, if libraries in
/usr/lib/scsh compiled with scsh 0.6.x are unlikely to work with scsh
0.7.x, it will cause headaches when upgrading from 0.6 to the 0.7
series. If this is the case, please think about using /usr/lib/scsh-0.6
instead, similar to what perl and python do. Ideally scsh-0.6 and
scsh-0.7 versions of the same package can be installed in parallel.
Apart from these issues, the proposal looks quite sound to me. Nice
work.
Regards,
Daniel.
|