Criando um pacote com mais de 60 binários e scripts. Onde os executáveis devem ser instalados?

Question

Estou no processo de criar um pacote para um kit de ferramentas de bioinformática que constrói várias dúzias de binários e scripts. Da forma como estão, todos esses são instalados no diretório 'bin' sob qualquer prefixo usado pelo gerenciador de pacotes. Eu corri isso pelas pessoas que mantêm o repositório de pacotes e isso fez com que eles franzissem a testa, já que cria muitas oportunidades para colisões de nomes de arquivos com outros pacotes.

A maioria dos usuários usa apenas cerca de 9 dos executáveis. O restante são programas utilitários, como conversores de formato de arquivo. Os gerenciadores de repositórios de pacotes sugeriram instalar os outros executáveis em um subdiretório sob a libexec. Isso seria bastante fácil de fazer, mas estou um pouco preocupado que não esteja de acordo com o propósito declarado da libexec na Hierarquia do Sistema de Arquivos. Padrão , uma vez que os executáveis são destinados a serem executados diretamente pelos usuários finais.

Existe um destino melhor para um pacote instalar várias dezenas de executáveis usados com pouca frequência?

    

Answer 1

libexec é bom, o postfix MTA, por exemplo, no RedHat tem um monte de ferramentas em /usr/libexec/postfix . Para outra opção mailman como empacotado no RedHat usa /usr/lib/mailman/bin para seus utilitários de linha de comando ( newlist , list_lists , etc).

no entanto, se os utilitários precisarem estar em PATH , você também precisará ajustar as configurações da shell para incluir isso (ou, em vez disso, apenas despejar tudo em um diretório bin e terminar com ele ou para os utilitários que não estão em PATH para qualificar totalmente o PATH para eles em coisas que precisam chamá-los ...)

    

Answer 2

Em um sistema de libexec -usuários, /usr/libexec/yourpackage está bem, como explicado por thrig . /usr/lib/yourpackage funciona em qualquer lugar.

Isso não resolve a questão do acesso. Adicionar o novo diretório ao caminho pode não ser apropriado, pois isso reintroduz o problema de colisão. Uma solução potencial é usar um script de inicialização em /usr/bin , no mesmo estilo que git com todos os seus subcomandos; vamos chamá-lo de bit (kit de ferramentas de bioinformática):

#!/bin/sh

prefix=/usr/lib/yourpackage/bin

if [ ! -x "${prefix}/$1" ]; then
    echo Unknown bit subcommand "$1"
    exit 1
fi

shift
exec "${prefix}/$1" "$@"

Depois que seus usuários mantiverem seus dedos, as ferramentas do seu pacote estarão razoavelmente acessíveis ...

    

Answer 3

Esteja ciente de que /usr/libexec/ (ou algum subdiretório nele, ou em outro lugar, por exemplo, sob /usr/lib ) não se destina (e não deve ser) no usuário $PATH , que pode ser tão curto quanto /bin:/usr/bin . Os executáveis nunca devem ser iniciados diretamente pelo usuário, apenas por algum outro programa específico (iniciado pelo usuário) (que não é um shell). Por exemplo, g++ está iniciando /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus (e o usuário não deve executar esse programa cc1plus diretamente).

Não há problema em ter um pacote instalando vários executáveis em /usr/bin/ (que está em $PATH ), e esse diretório deve ser bastante grande. Eu tenho mais de 4400 arquivos lá, e o único pacote coreutils instala mais de 100 arquivos executáveis nele.

Você pode decidir que o usuário do seu pacote sempre use um único programa de direção, um pouco como git .

Você pode compartilhar um prefixo comum para os executáveis do seu pacote. Por exemplo, todos os binários relacionados ao XFCE começam com xfce , e todos os binários do LXDE começam com lx . Na verdade, recomendo seguir uma convenção semelhante.

Ou você pode dividir seu pacote em vários, se fizer sentido não instalar alguns executáveis.

Você pode até criar sua embalagem para permitir que várias versões de seu conjunto coexistam (por exemplo, eu tenho gcc-6 e gcc-7 ).