Lisp package guidelines (Português) - ArchWiki

# Lisp package guidelines (Português)

From ArchWiki

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.

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.

Category:

- Package development (Português)