¿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-bary bar-foo. Mi paquete requiere uno de estos pero no ambos, y no me importa cuál esté presente. En tiempo de ejecución utilizo el 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 creo 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 empaque de bar-foo, no foo-bar, así 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. Digamos que foo-bar provides eagle' andbar-foo proporciona beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo`, y el sistema de destino puede tener uno o ambos instalados.
Actualmente me estoy inclinando a resolver esto con un %prescript que hace algo como:
rpm -q eagle || rpm -q beagle || echo "need eagle or beagle" && /bin/false
Si bien 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 lo preguntaste whatrequires foo-baro whatrequires beagle.
ACTUALIZACIÓN: Pensándolo bien, el dolor de exigir a las personas que instalen foo-bardonde no pueden ser menos que el dolor de eludir la gestión de la dependencia de RPM, al menos para mi situación. Entonces, a menos que a alguien se le ocurra una forma de requerir adecuadamente "esto O aquello" (lo cual creo que sería una gran característica para tener en general en RPM), planeo requerir solo foo-bar y luego, en tiempo de ejecución, si bar-fooestá disponible, elegiré entre ellos de acuerdo a cualquier criterio que necesite.
ACTUALIZACIÓN: otra idea, que también sería engañar a RPM pero podría llevar las cosas al estado correcto. Tal vez podría, en %post, jugar con la base de datos de RPM directamente. Por lo tanto %preme pudiera proteger de un inválido de instalar, y %postdiría retroactivamente RPM que requiero ya sea foo-baro bar-fooo ambos, dependiendo de lo que está allí cuando lo instale.
Gracias por las sugerencias!
Provides: foo-bar, de modo que satisfaga ambas dependencias. Para versiones más recientes de rpm, verifique las dependencias booleanas . Manténgase alejado de los%prey las%postsecciones, no trate de anular el sistema .Respuestas:
Esto ahora es posible a partir de RPM 4.13.
https://rpm.org/user_doc/boolean_dependencies.html
Puede ser simple como:
Requires: (pkgA >= 3.2 or pkgB)fuente
Este tipo de comportamiento ya lo realizan varios paquetes, por ejemplo, agentes de transporte de correo. Esos paquetes virtuales proporcionan a su sistema una forma de saber si algún otro programa ya proporciona la capacidad que necesitan.
Vea si el ejemplo de paquetes virtuales en rpm.org lo ayuda.
fuente
foo-barybar-foo, y dado que no controlo el empaquetado,foo-barno puedo hacer que ambos proporcionensupport-for-mypackage. Si controlara el paquete de ambos requisitos previos alternativos, entonces un paquete virtual compartido sería una gran solución.Dos posibilidades:
Si la parte de
foo-barybar-foousa es un archivo común, puede simplementeRequire /path/to/file(creo que sí; 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 unX-foo-barpaquete que requierafoo-bary unX-bar-foopaquete que requierabar-foo.fuente
foo-barpodría mover sus archivos (solo controlobar-fooaquí). Dependencias opcionales son interesantes, pero no es lo que necesitan, ya que realmente es necesario , ya seafoo-barobar-foo; lo único opcional es la elección de cuál. Gracias por responder.Require: /usr/bin/python3¿Funcionará para que su paquete bar-foo proporcione el paquete virtual foo-bar?
Luego puede hacer que su paquete burp-baz requiera foo-bar.
Si hacer lo anterior se siente incómodo (probablemente lo sea), es posible que necesite crear dos versiones de su RPM, una dependiendo de
foo-barla otra y la otrabar-foo.fuente
foo-bar, se rompería si creyera quebar-fooproporciona algo que realmente no es. El problema es que para mi paquete necesito cualquiera 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á disponible.El no determinismo en los sistemas automatizados (que es la administración de dependencias o las máquinas que usan RPM) es algo realmente malo. DESEA que falle en una situación de esto o aquello, ya que fallar aún no es tan malo como un resultado inesperado.
Para resolver el problema, tal vez haga que el paquete que controla% proporcione los tokens principales que el paquete inmutable también proporciona% y de los cuales depende su otro software%; entonces haga que su paquete% obsoleto sea el inmutable. Especialmente si ya está en su lugar, es posible que gane sobre la otra instalación.
Empaquetar y las operaciones de dependencia e instalación adecuadas es un trabajo complicado. El objetivo, instalaciones confiables, repetibles y auditables, es tan valioso que puede darse cuenta de las ganancias de hacerlo bien.
El infierno de dependencia es autoinfligido. Sin excepciones
fuente