Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] Discussion: Getting Common Lisp packages into Void
@ 2022-01-15 11:47 HiPhish
  2022-06-22  2:14 ` github-actions
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: HiPhish @ 2022-01-15 11:47 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 5162 bytes --]

New issue by HiPhish on void-packages repository

https://github.com/void-linux/void-packages/issues/35064

Description:
Hello everyone,

I would like to use this issue to discuss the addition of Common Lisp packages into Void. I am primarily interested in applications, which means we also need to package their dependencies as well. Adding every Common Lisp system out there as a library just for the sake of having it should not be the goal.

Here are some applications I can think of that rely on Common Lisp libraries:

- [StumpWM](https://stumpwm.github.io/index.html) (tiling window manager)
- [Nyxt](https://nyxt.atlas.engineer/) (web browser)
- Swank (a REPL server, part of [Slime](https://common-lisp.net/project/slime/))
- [CLPM](https://common-lisp.net/project/clpm/) (development package manager)
- [Quicklisp](https://www.quicklisp.org/) (another package manager)

Nyxt is already in Void, but it uses vendored dependencies, which can be a security risk: if any of the dependencies is compromised users have to wait for an upgrade to the Nyxt package (and any other future package that has the same dependency) to get the security leak plugged.

## Implementations

Common Lisp is an ANSI standardized language with many implementations. On GNU/Linux the most popular one is [SBCL](http://sbcl.org/), it loads and compiles Lisp code to native machine code. The result is written to "fasl" files (fast loading), but the fasl format of SBCL is not guaranteed to be portable between different versions of SBCL. Other implementations exist, such as [ABCL](https://abcl.org/) (runs on the JVM) or [ECL](https://common-lisp.net/project/ecl/) (gets embedded into another application), which have their own fasl format.

## Source or binary

How do you compile a Common Lisp system? You don't, you load it instead, either from source of from fasl if it exists. How to load which file and in which order is defined as part of the system in a `.asd` file. Considering the above diversity of implementations, I think we should make it possible for any implementation to load the same source instead of having separate packages like `sbcl-alexandria`, `abcl-alexandria`, `ecl-alexandria` and so on. It also means that the systems can be upgraded independently of the implementations, otherwise for `n` systems and `m` implementations we would have `n * m` possibilities.

This does have a downside however: whenever a system has been updated, the next time a dependent application is started users will have to wait for all the system to be recompiled. We could use ASDF (the de-facto build system) to pre-compile the Lisp code, but we would have to do so for each application individually.

We have thus two possibilities:

- Just install the source and whatever happens happens
- For a given application and its implementation: after installation go through all the dependencies and re-compile them

The latter is not much better than vendoring dependencies. To fix this we would need to go find all dependent packages on the user's system, find their implementation and re-compile the updated package. That's something more suited for a source-based package manager.

## Version confusion

This one is purely on the Common Lisp community, they are awful at keeping version numbers. Part of the problem is Quicklisp which will just take whatever the current Git version is, run the tests and ship it. Some projects use Git tags to tag release versions, but they won't update the version in the system definition. I don't know which one to trust then: the reported version which might not have changed in years, the tagged release, or just pull in whatever happens to be the current HEAD. I am in favor of the current release tag where applicable.

## Current progress

I have successfully packaged the [Alexandria](https://common-lisp.net/project/alexandria/) library as a test; it's a simple portable Lisp-only library that's used pretty much everywhere, it makes for a good first step. Here is the package definition:

```sh
pkgname=cl-alexandria
version=1.4
revision=1
hostmakedepends="bsdtar"
short_desc="Collection of portable Common Lisp utilities"
license="MIT, Public Domain"
homepage="https://common-lisp.net/project/alexandria/"
distfiles="https://gitlab.common-lisp.net/alexandria/alexandria/-/archive/v${version}/alexandria-v${version}.tar.gz"
checksum="0512aec38d054a20daa66e9983cf8a98151582d7e2307e49e8c1b4a61bbb779a"
build_style="fetch"
tags="common-lisp"

function do_install() {
	bsdtar -xf alexandria-v${version}.tar.gz
	cd alexandria-v${version}
	vmkdir '/usr/share/common-lisp/source/alexandria/'
	vlicense LICENCE
	vcopy *.asd '/usr/share/common-lisp/source/alexandria'
	vcopy alexandria-* '/usr/share/common-lisp/source/alexandria'
}
```

As you can see, it's mostly just me copying files over by hand. Tests are not run, but I should probably add that on the host side if not on the user side. The directory of the system (under `/usr/share/common-lisp/source`) must match the file name of the system's ASDF file (`alexandria.asd` in this case).

Thoughts and opinions?

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-10-10  2:14 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-15 11:47 [ISSUE] Discussion: Getting Common Lisp packages into Void HiPhish
2022-06-22  2:14 ` github-actions
2022-06-26 10:54 ` HiPhish
2022-09-25  2:14 ` github-actions
2022-10-10  2:14 ` [ISSUE] [CLOSED] " github-actions

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).