Pautas de Conflictos

Tenga en cuenta que los conflictos implícitos NUNCA son aceptables. Si su paquete entra en conflicto con otro, debe resolverlo o marcarlo con Conflicts:.

Algunos programas pueden utilizar otras aplicaciones opcionales si están presentes, pero no requieren su instalación. Si no están instaladas, el software seguirá funcionando correctamente. Sin embargo, si esas otras «aplicaciones opcionales» son demasiado antiguas, el software no funcionará. Este es un uso aceptable del campo Conflicts:. El empaquetador debe documentar el motivo en un comentario sobre el campo Conflicts::

Ejemplo:

Si el software enlaza con las bibliotecas de otro paquete, debe usar Requires: en lugar de Conflicts: para marcar esa dependencia. Además, si el software no funciona correctamente sin otro paquete instalado, debe usar Requires: en lugar de Conflicts:.

El paquete preguntaría:

Si el paquete (en la versión correcta) en Conficts: no está presente, ¿mi paquete será funcional?

Si la respuesta es sí, probablemente sea un uso válido de Conflicts:. Si la respuesta es no, casi con toda seguridad es mejor usar Requires:.

Por ejemplo, si tal-juego necesita libbar para ejecutar, pero no funcionará con libbar que es más antiguo que 1.2.3:

INCORRECTO: Conflictos: libbar < 1.2.3
CORRECTO: Requiere: libbar >= 1.2.3
Los empaquetadores deberían minimizar el uso de Conflictos:. Solo se permite la actualización desde dos versiones anteriores de Fedora, por lo que los conflictos con paquetes anteriores, aunque técnicamente correctos, son innecesarios y no deberían incluirse.

Si el contenido de un paquete se divide en un paquete independiente, el nuevo paquete suele contener archivos que también aparecen en el paquete original, lo que podría generar un conflicto implícito entre los archivos del nuevo paquete y los del original. Si el nuevo paquete depende del original, esto se puede resolver con un Requires versionado:

Si el nuevo paquete debe poder instalarse independientemente de si el paquete original está instalado, se permite un conflicto de versiones:

En ambos casos, la nueva versión del paquete original debe actualizarse para que no contenga los archivos conflictivos y dependa del nuevo paquete (al menos en todas las versiones estables de Fedora). Esto permite instalar las últimas versiones de ambos paquetes sin problemas. Los conflictos solo existen para resolver el caso en que se instala el nuevo paquete y la versión anterior del paquete original ya estaba instalada.

Es aceptable utilizar Conflicts: en algunos casos relacionados con paquetes de compatibilidad. En estos casos, no es posible parchear las aplicaciones para que busquen los archivos -compat en ubicaciones alternativas, por lo que los paquetes foo-devel y foo-compat-devel deben usar Conflict:. Siempre que sea posible, esto debe evitarse.

En el caso específico de que varios componentes de software generen binarios con nombres idénticos (pero incompatibles), los empaquetadores de Fedora deben hacer todo lo posible para convencer a los desarrolladores originales de renombrar los binarios para resolver el conflicto (véase: Conflictos de nombres binarios). Sin embargo, si ninguno de los desarrolladores originales está dispuesto a renombrar los binarios para resolver el conflicto, Y los binarios no son candidatos viables para alternativas o módulos de entorno (tiempos de ejecución incompatibles), siempre que no haya casos claros para que ambos paquetes se instalen simultáneamente, se permiten conflictos explícitos a discreción del empaquetador. En este caso, ambos paquetes deben tener conflictos.

Tenga en cuenta que añadir conflictos explícitos implica que, si otros paquetes dependen del suyo, podría estar creando una cadena de conflictos que podría causar problemas al usuario. Considere esto como último recurso.

Si la biblioteca es totalmente compatible con ABI, puede usar Módulos del Entorno para permitir al usuario alternar entre ellos. Si la biblioteca no es totalmente compatible con ABI, solicite a uno de los desarrolladores principales que cambie el nombre. Consulte Acercándose a Desarrollo para obtener ideas sobre cómo persuadir. Si ninguno de los desarrolladores principales cede, abra una solicitud al Fedora Packaging Committee para evaluar qué tipo de requisitos deberían implementar ambos paquetes para evitar conflictos en tiempo de ejecución.

Al renombrar o colocar archivos en subdirectorios, conviene contactar con el servidor principal para renombrar los archivos conflictivos (por ejemplo, si ambos tenían comandos llamados %{_bindir}/trash). Investigar cuál lleva más tiempo disponible puede ser útil en este caso, pero puede que no sea convincente para el servidor principal.

Si ninguno de los desarrolladores principales cambia el nombre, contactaríamos con otras distribuciones (distributions-list[at]freedesktop.org es un buen lugar para hablar sobre esto) para que el cambio de nombre sea posible en todas las distribuciones. Esto ayuda a los usuarios finales a mantener la coherencia al cambiar de una distribución a otra. La antigüedad de los proyectos, su popularidad y muchos otros factores pueden influir en esta decisión. Una vez tomada la decisión, renombraremos los paquetes de Fedora para que coincidan.

Se permiten nombres comunes para los comandos estándar, ya que estos serán los únicos que los implementarán. Los comandos estándar incluyen elementos previstos en estándares publicados y ampliamente implementados, como POSIX, y estándares de facto, como un programa que tradicionalmente se ha distribuido con un nombre de archivo específico en numerosas variantes de Unix. En caso de duda, envíe un mensaje a fedora-devel-list[at]redhat.com con detalles sobre en qué estándares aparece el comando, cuánto tiempo lleva disponible en qué sistemas Unix y si ha encontrado algún programa conflictivo que implemente un comando sustancialmente diferente con el mismo nombre de archivo.