Le lundi 28 mars 2022 à 09:59 +0200, Kambiz Darabi a écrit : > > So this email is essentially a call for volunteers. I will not > > disappear entirely, so I can certainly act as an adviser during a > > transition period. In particular, I would explain (or document) a few > > practices that I’ve been following so far (regarding version numbering > > and autopkgtests of CL libraries in particular). > > I would be happy to take over some of the tasks and I would > appreciate your documenting the practices, as you mentioned, > even it is only in a 'bullet list' style. Thanks for volunteering! Actually there is already a wiki page that documents the git packaging workflow: https://wiki.debian.org/Teams/DebianCommonLisp/GitPackaging Another important point worth mentioning is the versioning scheme for CL libraries. The practice I’ve been following is to remain close to what Quicklisp does: if a library has numbered releases (e.g. x.y.z) in Quicklisp, then do the same in Debian; on the other hand, if a library in Quicklisp tracks the latest commits in the Git upstream repository (now the most frequent case), then do the same in Debian with a version number of the form YYYYMMDD.gitXXXXXX (or even better, 0~YYYYMMDD.gitXXXXXX if this is a new package, to allow the transition to a numbered scheme at a later point, without adding an epoch). In both cases, packages should include a debian/watch file. Here is an example of the git versioning scheme: https://salsa.debian.org/common-lisp-team/cl-alexandria/-/blob/master/debian/watch In order to determine which numbering scheme is used by Quicklisp, one can have a look at this repository: https://github.com/quicklisp/quicklisp-projects For example, here is the file that shows that alexandria uses git versioning: https://github.com/quicklisp/quicklisp-projects/blob/master/projects/alexandria/source.txt Lastly, I’ve implemented autopkgtests in most CL library packages. When the package ships a testsuite, it is exercised against several implementations (typically SBCL, ECL, CLISP; I did not yet add autopkgtests against ABCL, because it is relatively new in the archive, and also it needs to be fixed to work with CFFI). If there is no usable testsuite, I added a “superficial” autopkgtest that simply tries to asdf:load-system the package in several implementations. Here is an example of a typical autopkgtest: https://salsa.debian.org/common-lisp-team/cl-alexandria/-/blob/master/debian/tests/runtests.lisp https://salsa.debian.org/common-lisp-team/cl-alexandria/-/blob/master/debian/tests/control > The most immediate task would be to update SBCL. I’ve given a try to > packaging version 2.2.2, but got across a problem I’ve reported > upstream (left unanswered so far): > https://bugs.launchpad.net/sbcl/+bug/1964511 > Maybe this problem can be worked around by putting the call to sb- > ext:set-sbcl-source-location in /etc/sbclrc, instead of trying to > modify the Lisp image at build time (though the latter is obviously > better). I will start by looking into this. Great, thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part