Lisp package guidelines (Português)

Status de tradução:
Esse artigo é uma tradução de
Lisp package guidelines
. Data da última tradução: 2019-06-27. Você pode ajudar a sincronizar a tradução, se houver
alterações
na versão em inglês.
Diretrizes de pacotes do Arch
32-bit
–
CLR
–
CMake
–
Cross
–
DKMS
–
Eclipse
–
Electron
–
Fonte
–
Free Pascal
–
GNOME
–
Go
–
Haskell
–
Java
–
KDE
–
Kernel
–
Lisp
–
Meson
–
MinGW
–
Node.js
–
Nonfree
–
OCaml
–
Perl
–
PHP
–
Python
–
R
–
Ruby
–
Rust
–
Shell
–
VCS
–
Web
–
Wine
No momento, há relativamente poucos pacotes
Lisp
disponíveis nos repositórios do Arch. Isso significa que, em algum momento ou outro, mais provavelmente aparecerá. É útil, portanto, descobrir agora, enquanto há poucos pacotes, como eles devem ser empacotados.
Nomenclatura e estrutura de diretórios
Há pelo menos um pacote no repositório base (
libgpg-error
) que inclui arquivos lisp, que são colocados em
/usr/share/common-lisp/source/gpg-error
. De acordo com isso, outros pacotes lisp também devem colocar seus arquivos em
/usr/share/common-lisp/source/
pkgname
.
O diretório do pacote deve ser o nome do pacote lisp, não o que é chamado nos
repositórios oficiais
do Arch (ou no
AUR
). Isso se aplica até mesmo a pacotes de arquivo único.
Por exemplo, um pacote Lisp chamado
"cl-ppcre"
deve ser chamado
cl-ppcre
no AUR e residir em
/usr/share/common-lisp/source/
cl-ppcre
. Um pacote Lisp chamado
"alexandria"
deve ser chamado
cl-alexandria
no AUR e residir em
/usr/share/common-lisp/source/
alexandria
.
ASDF
Tente evitar o uso do ASDF-Install como um meio de instalar esses pacotes em todo o sistema.
O próprio ASDF pode ser necessário ou útil como meio de compilar e/ou carregar pacotes. Nesse caso, sugere-se que o diretório usado para o registro central (a localização de todos os links simbólicos para
*.asd
) seja
/usr/share/common-lisp/systems/
.
No entanto, tenho observado problemas em fazer a compilação com asdf como parte do processo de compilação de pacotes. No entanto, ele funciona durante uma instalação, através do uso de um arquivo
pacote
.install
. Esse arquivo pode ser assim:
cl-ppcre.install
# arg 1:  the new package version
post_install() {
    echo "---> Compiling lisp files <---"

    clisp --silent -norc -x \
        "(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \
        (pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \
        (asdf:operate 'asdf:compile-op 'cl-ppcre)"

    echo "---> Done compiling lisp files <---"

    cat << EOM

    To load this library, load asdf and then place the following lines
    in your ~/.clisprc.lisp file:

    (push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
    (asdf:operate 'asdf:load-op 'cl-ppcre)
EOM
}

post_upgrade() {
    post_install $1
}

pre_remove() {
    rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}
}

op=$1
shift

$op $*
Obviamente, para este exemplo funcionar, é necessário que haja um link simbólico para
pacote
.asd no diretório do sistema asdf. Durante a compilação do pacote, um bloco como essa fará o truque...
pushd ${_lispdir}/systems
ln -s ../source/cl-ppcre/cl-ppcre.asd .
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .
popd
...sendo que
$_lispdir
é
$pkgdir/usr/share/common-lisp
. Ao vincular a um caminho relativo, em vez de absoluto, é possível garantir que o link não interromperá a pós-instalação.
Empacotamento específico do Lisp
Quando possível, não crie pacotes específicos para uma única implementação de lisp; tente ser tão multiplataforma quanto o próprio pacote permitir. Se, no entanto, o pacote for projetado especificamente para uma implementação única de lisp (ou seja, os desenvolvedores ainda não conseguiram adicionar suporte para outros, ou o propósito do pacote é especificamente fornecer um recurso integrado a outra implementação de lisp), é apropriado tornar o seu pacote Arch específico de lisp.
Se o pacote é independente da implementação, deve depender de
common-lisp
. Se o pacote possui suporte a várias implementações, mas não todas, você poderia (a) não fazer com que seu pacote dependa de *qualquer* lisp e incluir uma declaração no arquivo
package
.install informando às pessoas para ter certeza de que possuem um lisp compatível instalado (não ideal) ou (b) se baseie no PKGBUILD do
sbcl
e inclua uma declaração condicional para descobrir qual lisp é necessário (que envolve muito hacking e, novamente, longe do ideal). Outras ideias são bem-vindas.
Observe também que se o ASDF for necessário para instalar/compilar/carregar o pacote, as coisas podem ficar estranhas no que diz respeito às dependências. SBCL e CMUCL vêm com asdf instalado, mas o clisp não (mas há um pacote AUR).
As pessoas que atualmente mantêm pacotes específicos de lisp que não precisam ser específicos de lisp devem considerar fazer pelo menos um dos seguintes procedimentos:
Editar seus PKGBUILDs para serem multiplataformas, desde que outra pessoa não esteja mantendo o mesmo pacote para um lisp diferente.
Se oferecer para assumir a manutenção ou ajudar na manutenção do mesmo pacote para um lisp diferente e, em seguida, combiná-los em um único pacote.
Oferecer seu pacote ao mantenedor de uma versão diferente do mesmo pacote, para permitir que essa pessoa os combine em um único pacote.
Coisas que você, o leitor, pode fazer
Manter pacotes lisp seguindo essas diretrizes
Atualizar e corrigir problemas com essas diretrizes
Se manter atualizado com o que foi alterado aqui
Fornecer ideias, feedback e sugestões (educados) tanto para esse documento quanto para o trabalho das pessoas.
Traduzir essa página e atualizações futuras a esta página.