Le 9 mars 04, à 00:09, Daniel Kobras a écrit :
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.
That's very nice, I'm happy to get feedback from an experienced
packager.
My main concern is with install-pkg and its accompanying framework
being
included in each package. [...]
Ok, I think that's a valid concern.
The only advantage of the current scheme is that we are free to break
backward-compatibility for the installation library, because we know
that package authors have written their package definition so that it
works for the version of the installation library that *they* ship
along. But apart from that it has all the disadvantages you mention
(and a few other, like the fact that the installation library tends to
be duplicated in many separate CVS repositories). And if we include a
version identifier in package-definition files, as you suggest later,
we can at least give a nice error message to the user in case his
pkg-def.scm is too old for the installation library installed on his
system.
So I propose we do as you suggest, and distribute the installation
library as a separate package first, and when it stabilises, bundle it
with scsh (provided the main scsh authors agree, of course).
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.
Right. I'm just wondering how far we should go in that direction. The
most extreme (and probably the safest) option would be to say that
*all* files are put in a version-dependent directory, including Scheme
files.
With such a solution, the "scsh" layout would have scsh's version
number as a prefix for all directories, as follows (where <version>
represent the first two digits of scsh's version, i.e. 0.6 for the
current incarnation [I've seen they are accessible under the names
scsh-major-version and scsh-minor-version in scsh-version, in fact]):
base -> <version>/<package_full_name>
active -> <version>
scheme -> <version>/<package_full_name>/scheme
lib -> <version>/<package_full_name>/lib
doc -> <version>/<package_full_name>/doc
misc-shared -> <version>/<package_full_name>
while the "fhs" layout would be modified so that directories which are
currently named "scsh" only include a version number. We would get the
following mapping then:
base -> share/scsh-<version>/modules/<package_full_name>
active -> share/scsh-<version>/modules
scheme -> share/scsh-<version>/modules/<package_full_name>/scheme
lib -> lib/scsh-<version>/modules/<package_full_name>
doc -> share/doc/scsh-<version>/<package_full_name>
misc-shared -> share/scsh-<version>/modules/<package_full_name>
I like that solution personally, if nobody complains I'll modify the
layouts accordingly.
Apart from these issues, the proposal looks quite sound to me. Nice
work.
That's nice to hear, and thanks for your helpful comments.
Michel.
|