Como dois RPMs podem ser provedores mutuamente exclusivos da mesma funcionalidade?

2

Eu tenho um pacote breakfast que Requires toast , bacon e eggs . É importante ressaltar que breakfast precisa exatamente de uma implementação eggs para ser uma refeição balanceada.

O scrambled-eggs package Provides eggs . O mesmo acontece com o pacote fried-eggs . Em nenhuma circunstância, scrambled-eggs deve ser instalado ao lado de fried-eggs , mesmo na ausência de breakfast .

Se houvesse apenas duas maneiras de preparar ovos, a solução seria adicionar Conflicts: fried-eggs ao pacote scrambled-eggs e vice-versa. No entanto, existem muitas maneiras de preparar ovos, alguns dos quais ainda não são conhecidos, e uma nova maneira de preparar ovos pode não estar familiarizada com todas as outras maneiras de preparar ovos.

Curiosamente, parece que, para a versão 4.11.3 do RPM, você pode fazer com que cada pacote tenha Provides: eggs e Conflicts: eggs , mas esse comportamento não parece estar documentado. Na verdade, a documentação parece sugerir que não deve funcionar:

Conflicts are basically inverse Requires. If there is a matching package the package cannot be installed. It does not matter whether the Conflict: tag is on the already installed or to be installed package.

Posso confiar no comportamento Fornece / Conflitos acima para futuras versões do RPM? Ou, como mais posso resolver este problema?

    
por ToBeReplaced 20.04.2018 / 06:07

1 resposta

0

Resposta simples:

Não se trata de "funcionalidade".

"Fornece - geralmente lista quais arquivos são fornecidos (caminho completo) e" tags "(torradas, bacon, ovo) são incluídos." Tags "(vamos interpretar desta forma) DEVE ser exclusivo para algo muito específico, não o funcionalidade como MTA ou assim.

Você começa conflitos, quando várias versões de pacotes de mesmo nome não são permitidas ou "Provides" correspondem.

Basicamente, você NÃO DEVE interpretar "fornece" como "funcionalidade". Essa é a ideia.

    
por 01.05.2018 / 16:36

Tags