Pregunta ¿Se puede requerir un paquete de “este o ese” en un archivo de especificaciones de RPM?


¿Alguien sabe cómo (o si se puede) especificar un requisito alternativo o un conjunto de requisitos en un archivo de especificaciones, en lugar de un solo requisito?

Por ejemplo, digamos que hay dos paquetes disponibles, convenientemente nombrados foo-bar y bar-foo. Mi paquete requiere uno de estos pero no ambos, y no me importa cuál está presente. En el tiempo de ejecución utilizo lo que esté disponible.

Así que efectivamente me gustaría una manera de decir:

Requires: foo-bar OR bar-foo

Por lo que puedo decir, eso no es posible, pero me imagino que hay personas aquí que saben mucho más sobre RPM que yo, así que tal vez haya una manera de hacerlo.

ACTUALIZACIÓN: solo controlo el envasado de bar-foono foo-bar, por lo que tener ambos proporcionar un paquete virtual no funcionará.

ACTUALIZACIÓN: Lo que realmente necesito es en sí un paquete virtual Dentro de cada uno de los paquetes. Decir foo-bar provides eagle' andbar-foo proporciona beagleand my package works with either (or both); but other packages require eitheráguilaorbeagleorfoo-barorbar-foo`, y el sistema de destino puede tener uno o ambos instalados.

Actualmente me inclino por resolver esto con una %pre script que hace algo como:

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

Aunque estoy bastante seguro de que funcionaría, parece una elusión brutal del seguimiento de dependencias de RPM. Por ejemplo, nunca verías mi paquete cuando preguntaste. whatrequires foo-bar o whatrequires beagle.

ACTUALIZACIÓN: Pensándolo bien, el dolor de requerir que las personas instalen foo-bar donde podrían no ser menos que el dolor de burlar la administración de dependencias de RPM, al menos para mi situación. Entonces, a menos que a alguien se le ocurra una manera de exigir adecuadamente "esto O eso" (lo que creo que sería una gran característica para tener en RPM en general), entonces planeo requerir solamente  foo-bar y luego, en tiempo de ejecución, si bar-foo Está disponible. Elegiré entre ellos según el criterio que necesite.

ACTUALIZACIÓN: otra idea, que también sería engañar a RPM pero podría poner las cosas en el estado correcto. Tal vez podría, en %post, jugar con la base de datos de RPM directamente. Así %pre podría protegerme de una instalación inválida, y %post retroactivamente le diría a RPM que yo requiero foo-bar o bar-foo o ambos, dependiendo de lo que haya allí cuando instale.

Gracias por las sugerencias!


26
2017-08-09 11:42


origen


Sé que esto es muy viejo; ¿Pero hay una buena solución ahora para esto? Estoy haciendo un RPM que tiene java-1.6.0-openjdk en Requiere: línea; pero con java7; Me gustaría apoyar java-1.7.0-openjdk también, pero no pude encontrar una buena manera de poner cualquiera de esos dos en Requiere: - vpram86
Si controla el embalaje de bar-foo, una posible solución es construirlo con Provides: foo-bar, por lo que satisface ambas dependencias. Para versiones más nuevas de rpm, verifique Dependencias booleanas. Alejate de %pre y %post secciones, no intentes derrotar al sistema. - forcefsck


Respuestas:


Esto es ahora posible a partir de RPM 4.13.

https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_dependencies

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


10
2018-03-03 03:07



a partir del documento parece que no se pueden usar con requisitos, solo las dependencias "débiles" ¿correctas? - dsollen
El segundo enlace muestra que se pueden usar con los requisitos. El primer enlace menciona que el uso de esa manera no está permitido en Fedora, pero eso no se aplicará a los paquetes personalizados. - carlwgeorge


Este tipo de comportamiento ya lo realizan varios paquetes, por ejemplo, agentes de transporte de correo. Aquellos paquetes virtuales proporcione a su sistema una manera de saber si algún otro programa ya proporciona una capacidad que necesitan.

Ve si paquetes virtuales ejemplo en rpm.org te ayuda.


9
2017-08-09 11:53



Gracias. No creo que los paquetes virtuales resuelvan mi problema específico aquí, pero estoy de acuerdo en que son muy útiles. En mi caso, no quiero requerir alguna característica común proporcionada por ambos foo-bar y bar-foo, y como no controlo el embalaje de foo-bar No puedo hacer que ambos proporcionen support-for-mypackage. Si controlara el empaquetado de ambos requisitos previos alternativos, entonces un paquete virtual compartido sería una gran solución. - Kevin Frost


Dos posibilidades:

Si la parte de foo-bar y bar-foo Usted utiliza es un archivo común que puede simplemente Require /path/to/file (YO pensar asi que; mi prueba fue limitada).

Su situación es similar a las dependencias opcionales. La forma en que se manejan es tener un X-commonpaquete y luego tener una X-foo-bar paquete que requiere foo-bar y un X-bar-foo paquete que requiere bar-foo.


5
2017-08-09 20:25



No hay archivos comunes, por desgracia. Eso sería un buen truco si hubiera, aunque también potencialmente peligroso: alguna versión futura de foo-bar Podía mover sus archivos (solo controlo bar-foo aquí). Las dependencias opcionales son interesantes pero no son lo que necesito, ya que realmente las necesito. ya sea  foo-bar  o  bar-foo; Lo único opcional es la elección de los cuales. Gracias por responder. - Kevin Frost
¡Esto resolvió mi problema! Diferentes tipos de GNU / Linux proporcionan diferentes paquetes virtuales de python3: python3, python34, python35, etc. Para que mi paquete único funcione en todos ellos, solo pude usar Require: /usr/bin/python3 - bgStack15


¿Te funcionará que tu paquete bar-foo proporcione el paquete virtual foo-bar?

Entonces puedes simplemente hacer que tu paquete burp-baz requiera foo-bar.


Si hacer lo anterior se siente confuso (probablemente lo sea), es posible que deba crear dos versiones de su RPM, una dependiendo de foo-bar y el otro dependiendo de bar-foo.


0
2017-08-09 13:44



Tentador, pero peligroso: otra cosa que realmente necesita. foo-bar, entonces se rompería si pensara bar-foo estaba proporcionando algo que realmente no era. El punto de fricción es que para mi paquete que necesito ya sea de los requisitos previos pero no ambos; pero cualquier otro paquete realmente podría necesitar solo uno de ellos. Y tampoco puedo requerir ambos, ya que hay casos reales en los que solo uno u otro estarán disponibles. - Kevin Frost


La falta de determinismo en los sistemas automatizados (que es la administración de dependencias o las máquinas que usan RPM) es algo realmente malo. QUIERES que falle en una situación de "esto o aquello", ya que fallar no es tan malo como un resultado inesperado.

Para resolver el problema, tal vez haga que el paquete que usted controle% proporcione los tokens principales que el paquete inmutable también sucede para proporcionar% y de los cuales depende su otro software%; entonces tienes tu paquete% obsoleto al inmutable. Especialmente si ya está en su lugar, es posible que consiga ganar sobre la otra instalación.

Empaquetado y dependencia adecuada e instalación de operaciones es un trabajo difícil. El objetivo (instalaciones fiables, repetibles y auditables) es tan valioso que puede darse cuenta de las ventajas de hacerlo bien.

La dependencia del infierno es autoinfligida. Sin excepciones


-1
2018-05-10 21:46



Aquí está el pez que te daré: solo necesitas uno de los dos porque ambos proporcionan algún archivo o recurso. Entonces, no dependa del nombre del paquete, solo del archivo o recurso que proporcionan. Sí, aún estarás cortejando el no determinismo, pero si realmente estás considerando mezclar directamente con rpmdb, ya estás considerando alegremente los riesgos que la mayoría de las personas han aprendido a evitar. Espero que pueda encontrar una solución que no incurra en tal deuda técnica. - user2066657