Equivs: melhora ou atualiza um pacote existente sem desinstalar?

Question

Algumas informações: Estou usando o Debian 7 como meu ambiente principal e quero dizer ao meu sistema que tenho glibc = 2.15 além do glibc = 2.13 exigido pelo ambiente para uso de alguns aplicativos mais recentes.

Eu obtive o glibc dos vários tutoriais na web para instalar, por exemplo: Steam. Ele é descompactado em /usr/local/lib/libc6-2.15 e eu testei com alguns aplicativos como o Pidgin 2.10, Boinc 7 e Stellarium, ele está funcionando bem (até agora, eu faço espera que eventualmente falhe normalmente). Como seria muito melhor se eu pudesse instalar esses aplicativos também de fontes empacotadas (tanto o clang quanto o Boinc estão em teste, por exemplo), gostaria de dizer ao meu sistema por meio de um pacote virtual que, na verdade, tenho um glibc 2.15 disponível.

É claro que eu sei sobre equivs como uma ferramenta para criar pacotes virtuais para coisas que não foram instaladas a partir de repositórios, mas não encontrei nenhuma boa documentação sobre como usar equivs para criar um pacote virtual que pode atualizar um pacote já instalado, idealmente sem quebrar.

Eu primeiro tentei o óbvio:

Package: libc6
Version: 2.15-1

E instalou o pacote gerado pelo dpkg, com o resultado esperado de que ele desinstalasse o já existente libc para atualizar e deixasse o sistema em um estado inutilizável. (Claro, eu tentei isso em uma VM). Eu também tentei

Version: >= 2.13

Sem bons resultados.

Eu tentei procurar uma maneira de usar Fornece ou Aprimora criando um pacote com um nome diferente

Package: local-libc6
Version: 2.15
# Either this:
Provides: libc6
# Or this:
Enhances: libc6 (< 2.15)

Mas até agora não tive sucesso em conseguir que o equivs criasse um pacote instalável (o aptitude reclama sobre um Provides ou Enhances inválido), ou até mesmo para criar um pacote.

Naturalmente, a ideia é criar um pacote virtual para libc que não desinstale o já instalado e simplesmente "forneça" a nova versão. Mas eu achei a documentação horrivelmente carente a esse respeito até agora (e eu realmente não quero ter que me aprofundar e me perder na Enciclopédia DPKG; geralmente eu tenho disposição e tempo para fazer essas tarefas, mas atualmente meu foco é necessário em outro lugar).

Então, eu acho que a questão básica é: can eu uso equivs para criar uma atualização para um pacote sem desinstalar o original, ou conseguir algo para esse efeito? Quais cuidados gerais eu preciso exercitar ao especificar versões para equivs ?

    

Answer 1

A resposta é que um pacote criado com equivs-build de um arquivo de controle que contém uma variação no nome (libc6-local por exemplo) de um pacote existente e uma versão superior, acionará a remoção do pacote antigo , não por causa da execução para prerm ou postrm scripts do pacote novo ou antigo, mas por design .

Agora, é possível criar um pacote com um nome totalmente diferente e definir no arquivo de controle que fornece um pacote como o libc6. Mais especificamente, considere o seguinte arquivo de controle (apenas a parte relevante mostrada) para um pacote virtual proposto:

Package: 6cbil-local //libc6 backwards is good enough
Version: 2.9
Provides: glibc-2.9
Section: libs

Compare isso com o arquivo de controle em libc6 2.17-0ubuntu5 (minha máquina):

Package: libc6
Source: eglibc
Version: 2.17-0ubuntu5
Architecture: amd64
Maintainer: Ubuntu Developers <[email protected]>
Installed-Size: 10441
Depends: debconf (>= 0.5) | debconf-2.0, libgcc1
Suggests: glibc-doc, locales
Conflicts: prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch
Breaks: lsb-core (<= 3.2-27), nscd (<< 2.17)
Replaces: libc6-amd64
Provides: glibc-2.17-1
Section: libs
Priority: required
Multi-Arch: same

Em seguida, considere um pacote vazio com base nesse arquivo de controle:

Package: using6
Version: 1.0
Depends: libc6 (= 2.9) // it requires that specific version

Em seguida, crie os pacotes. Nosso pacote virtual que fornece o glib-2.9 instala e não remove nenhuma libc6 instalada . Quando você tenta instalar nosso pacote que depende do glibc-2.9, obtemos um erro em apt (configurado como 2.2 aqui ):

The following packages have unmet dependencies:
 using6 : Depends: libc6 (= 2.9) but 2.17-0ubuntu5 is to be installed
E: Unable to correct problems, you have held broken packages.

ou dpkg :

dpkg: dependency problems prevent configuration of using6:
 using6 depends on libc6 (= 2.9); however:
  Version of libc6:amd64 on system is 2.17-0ubuntu5.

Volte para o nosso pacote virtual inicial e substitua o que ele fornece:

Provides: glibc-2.9, libc6

Em seguida, tente reinstalar o nosso pacote que depende do glibc-2.9. dpkg fornece a mesma mensagem de erro, mas não apt !!!! O Apt realmente mudou de idéia no minuto em que eu construí os pacotes depois de alterar o valor de fornecimento, em seguida, enviei as alterações para o Packages.gz e atualizei o apt com dpkg-scanpackages dirwithpackages | gzip > dirwithpackages/Packages.gz then sudo apt-get update :

The following packages have unmet dependencies:
 using6 : Depends: libc6 (= 2.9) //notice the reference to 2.17 is gone!!
E: Unable to correct problems, you have held broken packages.

Isso é um pouco diferente da explicação que eu perdi no Manual do Debian :

5.2.1.4.3. Limitações Atuais

Pacotes virtuais sofrem de algumas limitações preocupantes, sendo a mais significativa a ausência de um número de versão. Para retornar ao exemplo anterior, uma dependência como Depends: libdigest-md5-perl (> = 1.6), apesar da presença de Perl 5.10, nunca será considerada como satisfeita pelo sistema de empacotamento - enquanto na verdade é mais provável que seja satisfeito. Desconhecendo isso, o sistema de pacotes escolhe a opção menos arriscada, assumindo que as versões não combinam.

GOING FURTHER Virtual package versions Although today virtual packages can't have versions, this will not necessarily always be the case. Indeed, apt is already able to manage the versions of virtual packages and it is likely that dpkg eventually will too. We will then be able to write fields such as Provides: libstorable-perl (= 1.7) to indicate that a package provides the same functionality as libstorable-perl in its 1.7 version.

A experiência acima mostra que apt e dpkg se comportaram de maneira um pouco diferente (na medida em que as mensagens de erro mudam) com minha configuração (Xubuntu 13.04, dpkg = 1.16.10 (amd64) e apt = 0.9.7.7ubuntu4 (amd64) ). Apt reconhece que vê que este pacote que instalamos fornece libc6, mas não vê que ele forneça exatamente a versão 2.9. Por fim o apt chama o dpkg para que o dpkg seja o gargalo.

It seems on my setup the only value that makes a difference for "Provides" in a control file under your scenario is libc6. But that won't be enough to allow installing software with reliance on a specific version because of current limitations and design.

Por fim, como você sabe, o ld.config.so é o instalação para cuidar de todos os links, como demonstrado em este exemplo da cadeia de ld arquivos e diretórios .so.conf. A infra-estrutura de vinculação e a variável $ LD_LIBRARY_PATH para objetos compartilhados têm prioridade sobre os locais padrão da biblioteca, como / lib e / usr / lib nesse contexto.