Arch Linux e dependências opcionais

Question

Eu instalei o XChat em um sistema Arch Linux. Toda vez que eu executo, recebo a seguinte mensagem de erro:

Python interface loaded
Perl interface loaded
AutoLoad failed for: /usr/lib/xchat/plugins/tcl.so
libtcl8.5.so: cannot open shared object file: No such file or directory

Então, enquanto os plugins para Python e Perl são carregados corretamente, o plugin Tcl não é. Na verdade, python2 e perl packages estão instalados no meu sistema, enquanto tcl package não está. Instalar tcl corrige o problema.

Antes de instalar o tcl , obtenho:

ldd /usr/lib/xchat/plugins/tcl.so | grep tcl
    libtcl8.5.so => not found

Depois de instalar o tcl , obtenho:

ldd /usr/lib/xchat/plugins/tcl.so | grep tcl
    libtcl8.5.so => /usr/lib/libtcl8.5.so (0x00007fceba533000)

Parece que tcl não é uma dependência obrigatória de xchat , mas sim uma opção opcional:

pacman -Qi xchat
...
Optional Deps  : enchant: for spell checking support
                 tcl: for tcl plugin
                 python2: for python plugin
...

Por que isso acontece? Por que o pacote tcl não está instalado junto com xchat por padrão? Não é xchat quebrado sem tcl ?

Eu registrei um bug há mais de dois anos, mas nunca entendi porque as coisas são assim no Arch Linux terra. Por favor note que enquanto este bug é antigo, eu só estou executando esta distribuição diariamente desde alguns meses, então eu sou um novato no Arch Linux.

Eu poderia ter perguntado em fóruns ou listas de discussão do Arch Linux, mas estou bastante interessado em conhecer o ponto de vista de outros usuários de distribuições Linux. Os usuários do Arch Linux também são bem-vindos, é claro.

EDITAR

1. A mensagem de erro que recebo ao executar o XChat sem o tcl instalado é claramente visível na GUI, no mesmo local em que as mensagens são exibidas.
2. Minha pergunta também pode ser reformulada da seguinte maneira: por que o XChat, apesar de ter sido criado com --enable-tcl ou equivalente passado para o script configure , pode ser instalado sem uma dependência obrigatória no pacote tcl ? Se você não quiser tcl , ele deve usar --disable-tcl .

EDIT. Eu abri um tópico no fórum Arch Linux, mas não obtive uma resposta satisfatória. Então eu verifiquei o Debian e o Gentoo, e parece que eles não têm esse problema.

    

Answer 1

É principalmente uma questão de complexidade e como as pessoas escolhem investir seu tempo.

Se você quiser um pacote binário do XChat que não mostre nenhum aviso / erro relacionado à falta de bibliotecas para plugins, você tem basicamente duas opções:

• inclua apenas / configure plug-ins "vitais" e adicione dependências complexas para o que essas coisas exigem
• inclua todos os plug-ins disponíveis e adicione dependências complexas para o que essas coisas exigem

A primeira opção deixa você com um pacote XChat que não tem muitos recursos. Você precisaria então de um xchat-perl package, um xchat-tcl one, um xchat-gtk , ... Todos esses pacotes precisam ser mantidos, corrigidos, atualizados, etc. Isso é muito trabalho.

A segunda opção oferece um pacote XChat inchado que atrai muitas outras coisas, a maioria das quais não será usada pelo usuário médio. Não é realmente satisfatório para distribuições como Arch.

Você pode tentar encontrar um ponto ideal entre esses dois, mas provavelmente não encontrará o ajuste perfeito.

O que o Arch devs aparentemente fez com o pacote é enviar um plugin comumente usado sem forçar o usuário a instalar a dependência. Isso (deixando de fora a mensagem de erro por enquanto) é realmente muito bom para o usuário: aqueles que não querem / precisam do TCL não precisam instalá-lo para obter o XChat. Aqueles que o fazem podem apenas instalar o TCL e o plugin XChat TCL apenas irá funcionar.
Então, isso é um bom compromisso. Se você, no futuro, quiser usar o TCL para fazer o script do seu XChat, tudo o que você terá que fazer é instalar o TCL - você não terá que se preocupar em atualizar o XChat ou instalar outro pacote.

Quanto à mensagem de erro, é puramente estético. Poderia ser consertado? Provavelmente,
Poderia ser corrigido facilmente de uma forma que ainda permite que o plug-in comece a funcionar logo após a instalação do TCL (sem pacotes adicionais ou alterações de configuração, verificações de dependência reversa, ...): isso não é tão certo.
Os desenvolvedores / mantenedores do Arch devem gastar tempo tentando remover esse problema estético? Isso é discutível. Dando que o software funcione, isso deve ter uma prioridade bem baixa.

Poderia você tentar corrigi-lo de uma forma ou de outra? Se é importante o suficiente para você, provavelmente. Dê uma olhada: encontre uma maneira melhor de lidar com esses plugins e dependências, registre uma solicitação de bug ou recurso ou entre na lista de discussão / fórum apropriada para esse tipo de coisa.
Distros de código aberto não melhoram por mágica. Se você se importa bastante com isso, envolva-se.

    

Answer 2

why XChat, despite having clearly been built with --enable-tcl or equivalent passed to the configure script, can be installed without a mandatory dependency on the tcl package?

Você está usando o Arch Linux. Do FAQ - O que torna o Arch exclusivo ... :

Arch packaging is designed to be minimal, and optional package dependencies are never automatically installed. Rather, the user is simply notified of their existence during package installation, resulting in a slimmer system.

Detalhes do pacote XChat :

dbus-glib
gtk2
hicolor-icon-theme libnotify
openssl
enchant (optional) - for spell checking support
python2 (optional) - for python plugin
tcl (optional) - for tcl plugin

EDIT: Em resposta ao seu comentário abaixo:

Não tenho certeza se entendi o que você quer dizer ... Dependências opcionais são usadas apenas para determinados recursos / funcionalidades de um aplicativo. Essas dependências NÃO são necessárias se os recursos não forem usados. Dependências opcionais são geralmente usadas quando, por várias razões, não é realmente possível dividir um pacote em submódulos (um sub-módulo teria apenas dependências não-opcionais, já que você precisaria de todas elas para usar esse sub-módulo). funcionalidade do módulo). Um exemplo de pacote + sub-módulos é exaile .

Agora, sobre aquela mensagem de erro / aviso que você estava chegando lá ... Eu acho que o Mat praticamente resumiu em seu post e eu realmente não tenho mais nada a acrescentar.