Pode-se exigir o pacote "this OR that" em um arquivo de especificação do RPM?

30

Alguém sabe como (ou se pode) especificar um requisito alternativo ou conjunto de requisitos em um arquivo de especificação, em oposição a um único requisito?

Por exemplo, diga que existem dois pacotes disponíveis, convenientemente nomeados foo-bare bar-foo. Meu pacote exige um desses, mas não ambos, e não me importo com qual deles esteja presente. Em tempo de execução, uso o que estiver disponível.

Tão eficazmente, eu gostaria de uma maneira de dizer:

Requires: foo-bar OR bar-foo

Até onde eu sei, isso não é possível, mas acho que há pessoas aqui que sabem muito mais sobre RPM do que eu, então talvez haja uma maneira de fazê-lo.

ATUALIZAÇÃO: Eu apenas controlo o empacotamento bar-foo, não foo-bar, portanto, ter ambos fornecendo um pacote virtual não funcionará.

ATUALIZAÇÃO: O que eu realmente preciso é um pacote virtual dentro de cada um dos pacotes. Digamos foo-bar provides eagle' andbarra-foo fornece beagle and my package works with either (or both); but other packages require eitheráguia orbeagle orfoo-bar orbar-foo`, e o sistema de destino pode ter um ou ambos instalados.

Atualmente, estou inclinado a resolver isso com um %prescript que faz algo como:

rpm -q eagle || rpm -q beagle || echo "need eagle or beagle" && /bin/false

Embora tenha certeza de que funcionaria, parece uma brutal evasão ao rastreamento de dependências do RPM. Por exemplo, você nunca veria meu pacote quando pedisse whatrequires foo-barou whatrequires beagle.

ATUALIZAÇÃO: Pensando bem, a dor de exigir que as pessoas instalem foo-baronde elas não podem é menor que a dor de contornar o gerenciamento de dependências de RPM, pelo menos para a minha situação. Portanto, a menos que alguém encontre uma maneira de exigir adequadamente "isto ou aquilo" (o que eu acho que seria um ótimo recurso para o RPM em geral), planejo exigir apenas foo-bar e, em tempo de execução, se bar-fooestiver disponível, vou escolher entre de acordo com os critérios que eu precisar.

UPDATE: outra idéia, que também estaria enganando o RPM, mas poderia colocar as coisas no estado certo. Talvez eu pudesse %postmexer diretamente com o banco de dados do RPM. Assim %prepoderia me proteger de um inválido instalar, e %postteria efeitos retroactivos dizer RPM que eu exigir quer foo-barou bar-fooou ambos, dependendo do que está lá quando eu instalar.

Obrigado pelas sugestões!

rpm

— Kevin Frost
fonte

Eu sei que isso é muito antigo; mas existe uma boa solução agora para isso? Estou criando um RPM com java-1.6.0-openjdk em Requer: linha; mas com java7; Gostaria de suporte java-1.7.0-openjdk tão bem, mas não conseguia descobrir uma boa maneira de colocar qualquer um dos dois em Requer:

— vpram86

Se você controla o empacotamento do bar-foo, uma solução possível é construí-lo Provides: foo-bar, para satisfazer as duas dependências. Para versões mais recentes do rpm, verifique Dependências booleanas . Fique longe de seções %pree não tente derrotar o sistema . %post

— forcefsck

13

Agora isso é possível a partir do RPM 4.13.

https://rpm.org/user_doc/boolean_dependencies.html

Pode ser simples como: Requires: (pkgA >= 3.2 or pkgB)

— Carlwgeorge
fonte

do documento que parece que não pode ser usado com requer, apenas as dependências 'fracas' estão corretas?

— Dsollen

O segundo link mostra que eles podem ser usados com o Requer. O primeiro link menciona que não é permitido usá-lo dessa maneira no Fedora, mas isso não se aplica a pacotes personalizados.

— Carlwgeorge

9

Esse tipo de comportamento já é feito por vários pacotes, por exemplo, agentes de transporte de correio. Esses pacotes virtuais fornecem ao seu sistema uma maneira de saber se um recurso que eles precisam já foi fornecido por algum outro programa.

Veja se o exemplo de pacotes virtuais no rpm.org ajuda você.

— Janne Pikkarainen
fonte

Obrigado. Não acho que os pacotes virtuais resolvam meu problema específico aqui, mas concordo que sejam muito úteis. No meu caso, não quero exigir algum recurso comum fornecido por ambos foo-bare bar-foo, e como não controle a embalagem, foo-barnão posso apenas fazê-los fornecer support-for-mypackage. Se eu controlasse o empacotamento de ambos os pré-requisitos alternativos, um pacote virtual compartilhado seria uma ótima solução.

— Kevin Frost

5

Duas possibilidades:

Se a parte de foo-bare bar-foovocê usar for um arquivo comum, você pode apenas Require /path/to/file( acho que sim; meus testes foram limitados).

Sua situação é semelhante às dependências opcionais. A maneira como eles são tratados é ter um X-commonpacote e, em seguida, um X-foo-barpacote que requer foo-bare um X-bar-foopacote que requer bar-foo.

— Mark Wagner
fonte

Infelizmente não há arquivos comuns. Isso seria um truque legal se houvesse, embora também potencialmente perigoso: alguma versão futura do foo-barpoderia mover seus arquivos (eu só controlo bar-fooaqui). Dependências opcionais são interessantes, mas não exatamente o que eu preciso, pois eu realmente preciso de um foo-bar ou bar-foo ; a única coisa opcional é a escolha de qual. Obrigado por responder.

— Kevin Geada

Isso resolveu meu problema! Diferentes tipos de GNU / Linux fornecem diferentes pacotes virtuais python3: python3, python34, python35, etc. Para que meu pacote único funcione em todos eles, eu apenas consegui usáRequire: /usr/bin/python3

— lo

0

Será que vai funcionar para que o seu pacote bar-foo forneça o pacote virtual foo-bar?

Você pode fazer o seu pacote burp-baz exigir foo-bar.

Se o procedimento acima parecer esquisito (provavelmente é), você poderá criar duas versões do seu RPM, uma dependendo foo-bare a outra dependendo bar-foo.

— MikeyB
fonte

Tentador, mas perigoso: outra coisa, que realmente precisa foo-bar, se romperia se pensasse bar-fooestar fornecendo algo que realmente não era. O ponto principal é que, para o meu pacote, preciso de um dos pré-requisitos, mas não de ambos; mas qualquer outro pacote pode realmente precisar de apenas um deles. E também não posso exigir os dois, pois há casos reais em que apenas um ou outro estará disponível.

— 91111 Kevin Frost

-2

Não-determinismo em sistemas automatizados (que é o gerenciamento de dependências ou as máquinas que usam RPMs) é uma coisa muito ruim. Você QUER fracassar em uma situação como essa ou aquilo, pois a falha ainda não é tão ruim quanto um resultado inesperado.

Para resolver o problema, talvez o pacote que você controla% forneça os principais tokens que o pacote imutável também fornece% e de que% o seu outro software depende; então, seu pacote% obsoleta o imutável. Especialmente se ele já estiver no lugar, você poderá vencê-lo na outra instalação.

Empacotar e dependência adequada e operações de instalação é um trabalho complicado. O objetivo - instalações confiáveis, repetíveis e auditáveis - é tão valioso que você pode perceber os ganhos de fazê-lo corretamente.

O inferno da dependência é auto-infligido. Sem exceções

— user2066657
fonte

Aqui está o peixe que darei a você: você precisa de apenas um dos dois porque ambos fornecem algum arquivo ou recurso. Portanto,% não depende do nome do pacote, apenas do arquivo ou recurso que eles fornecem. Sim, você ainda estará cortejando o não-determinismo, mas se estiver realmente pensando em mexer com o rpmdb diretamente, já estará considerando alegremente os riscos que a maioria das pessoas aprendeu a evitar. Espero que você encontre uma solução que não incorra em dívida técnica.

— user2066657