Lisp package guidelines (Português)
CLR – Cross – Eclipse – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – MinGW – Node.js – Nonfree –OCaml – Perl – PHP – Python – R – Ruby – 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.
Contents
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.
Para evitar tornar os pacotes específicos da implementação, idealmente todos os pacotes de implementação (SBCL, cmucl, clisp) seriam construídos com o campo PKGBUILD common-lisp. No entanto, esse não é o caso (e isso provavelmente causaria problemas para pessoas que preferem ter vários lisps na ponta dos dedos). Enquanto isso, 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 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, já que o SBCL vem com asdf instalado, enquanto o clisp não, mas há um pacote AUR e a CMUCL pode ou não tê-lo.
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.