[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Manpower in Debian Common Lisp Team

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

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:

In order to determine which numbering scheme is used by Quicklisp, one
can have a look at this repository:
For example, here is the file that shows that alexandria uses git

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:

> 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

Reply to: