Proceso de Nuevo Paquete para Nuevos Colaboradores
Esta es una versión larga del Proceso de Nuevo Paquete, contiene más detalles de modo que los nuevos colaboradores lo puedan seguir más fácilmente. También se incluye un paso obligatorio de patrocinador.
Comprobar si el paquete ya existe
Si algún software útil no está incluido ya en Fedora puede enviarlo como un nuevo paquete. El paquete que envíe puede ser de cualquier proyecto Libre y de Código Abierto.
Antes de crear su paquete, compruebe que el software no está ya en el repositorio Fedora:
-
Compruebe si el paquete ya existe buscando en Fedora Packages.
-
Search in the Review Tracker for packages under review.
-
Compruebe los paquetes huérfanos o retirados que necesitan mantenedores.
-
Este atento a los elementos prohíbidos.
Hacer un Paquete
-
If you don’t know how to create an RPM package, see the Packaging Tutorial.
-
Asegúrese de que su paquete cumple las Directrices de Empaquetamiento y las Directrices de Denominación de Paquetes.
-
Esté atento a las Directrices de Revisión de Paquetes (serán usadas durante la revisión del paquete).
-
Asegúrese de que su paquete se construya. Esto es sorprendentemente importante porque un número significativo de envíos no lo hace.
Suba Su Paquete
Suba sus archivos SRPM y SPEC en algún lugar de Internet para que otros puedan recuperarlos. Este puede ser cualquier lugar al que se pueda acceder mediante una URL, pero es importante que los archivos sean directamente accesibles, no escondidos en algún lugar que haga esperar a la gente para descargar cosas o redireccione a través de páginas publicitarias.
Si desea que las compilaciones estén accesibles para los usuarios mientras ingresa el paquete en los repositorios oficiales, considere usar Copr. Es un sistema de compilación automatizado liviano que puede crear repositorios utilizando el SRPM que usted carga. Puede usar este espacio Copr para indicar a los revisores su src.rpm y sus especificaciones.
Crear Su Solicitud de Revisión
Complete el formulario de revisión de Bugzilla Fedora.
-
Before submitting your request, be sure there’s not a previous request for the same package. There is a convenient search box on the package review status page.
-
Asegúrese de que pone el nombre del paquete (excluyendo número de versión y de lanzamiento) en el campo
Review Summary
, junto con un muy breve resumen de lo que es el paquete. -
Ponga una descripción de su paquete (normalmente, esto puede ser lo mismo que ha puesto en la especificación
%description
) en el campoReview Description
. Incluya las URLs a sus archivos SRPM y SPEC. -
Explique en el ticket que este es su primer paquete y que necesita un patrocinador. También, incluya cualquier información que pueda ayudar a los posibles patrocinadores. Si ha estado activo en otro trabajo de revisión, incluya enlaces. Si es el mantenedor upstream, asegúrese de decirlo.
-
Para obtener puntos de bonificación, incluya un enlace a una construcción koji exitosa para que todos sepan que hizo toda su tareas.
El proceso de revisión se describe en detalle en la página Proceso de Revisión del Paquete.
Informar al Upstream
El Proyecto Fedora prefiere Mantenerse Cerca de los Proyectos Upstream. Informe a los desarrolladores que está empaquetando el software. Puede hacer esto enviándoles un correo electrónico presentándose y señalándoles la solicitud de revisión. Esto prepara el escenario para futuras conversaciones. Por lo general anunciarán el hecho de que su software es ahora parte de Fedora o querrán informarle sobre errores importantes en la versión existente, hoja de ruta futura, etc.
Esté Atento a los Comentarios
Mire el informe Bugzilla para su primer paquete. Debería recibir notificaciones de cambios por correo electrónico. Corrija los obstáculos que los revisores señalen.
Obtener Patrocinio
Cuando el paquete es APROBADO por el revisor, debe obtener patrocinio de miembros por separado para poder registrarse y crear su paquete. El patrocinio no es automático y puede requerir que usted participe de otras maneras para demostrar su comprensión de las directrices de empaquetamiento. La claves para llegar a ser patrocinado es que convenza a un miembro con nivel de patrocinador de que entiende y sigue las directrices y procesos del proyecto.
Vea Como Obtener Patrocinio en el Grupo Empaquetador para más información sobre el proceso para llegar a ser patrocinado.
Su patrocinador le puede añadir al grupo empaquetador. Debería recibir un correo electrónico de confirmación de su patrocinio.
Añadir un Paquete al sistema de Administración de Código Fuente (SCM) y Establecer el Propietario
Antes de proceder, sincronice su cuenta accediendo a las Fuentes de Paquetes Fedora usando sus credenciales FAS.
Si se convierte en mantenedor de un nuevo paquete, en lugar de comantenedor, use fedpkg para solicitar un nuevo repositorio git para su paquete. El subcomando es fedpkg request-repo
que incluye texto de ayuda para configurar el token API de Pagure que el comando requiere. Al crear su clave API elija alternar todo para las ACLs. Debe especificar el nombre del repositorio y revisar el número de error. Por ejemplo:
fedpkg request-repo python-prometheus_client 1590452
La solicitud será revisada y procesada automáticamente. Después del procesamiento, tendrá acceso para confirmar y compilar el paquete. En el caso de que la automatización no funcione, puede reportar el problema al rastreador de cuestiones Toddlers.
fedpkg request-repo
only creates a branch for Rawhide. To request branches for other Fedora releases, see Requesting branches.
Consultar el repositorio de distgit
Usted podría consultar su repositorio distgit ahora, pero antes de hacer esto, considere hacer mkdir ~/fedora-scm ; cd ~/fedora-scm
— de esta forma, todos sus archivos estarán dentro de un único directorio. También, ejecute ssh-add
, para que no tenga que seguir escribiendo su clave contraseña.
Ahora está preparado para consultar su repositorio distgit desde el SCM:
fedpkg clone your-package
Probar Su Paquete
Vea Usar Mock para probar las compilaciones de paquete y Koji Scratch Builds para más información sobre las pruebas de su paquete. Mock usa su sistema local, mientras que la herramienta en línea de comando Koji usar el servidor del sistema de compilación Fedora.
Importar, confirmar y crear su paquete
Ahora que ha comprobado su repositorio distgit (vacío) con fedpkg
, acceda a la rama principal del repositorio:
cd <packagename>
Run fedpkg to import the contents of the SRPM into the SCM:
fedpkg import PATH_TO_SRPM
# Review Changes, press 'q' to stop; Revert with: git reset --hard HEAD git commit -m "Initial import (fedora#XXXXXX)." git push fedpkg build
Obviously, replace PATH_TO_SRPM
with the full path (not URL) to your approved SRPM, and XXXXXX
with the package review bug number.
If your package is using autochangelog, writing the bug number as specified will make the Fedora update system automatically close the bug when your package is submitted to Rawhide stable repository.
This imports into, commits, and builds only the main (Rawhide) branch.
If the push fails with this kind of message:
W access for why DENIED to YOUR_ACCOUNT fatal: The remote end hung up unexpectedly Could not push: Command '['git', 'push']' returned non-zero exit status 128
Then you don’t have the necessary rights to modify that package branch. View https://src.fedoraproject.org/rpms/PACKAGE_NAME
to request those rights.
For more information on using the Fedora package maintenance system, see the Package maintenance guide.
Actualizar Sus Ramas (si lo desea)
Las ramas son f#
(anteriormente F-
y antes de eso FC-
), main
, etc. Así, So f
is the branch for Fedora.
Cambie a una rama primero:
fedpkg switch-branch BRANCH
(e.g. f40
)
Merge the initial commit from main (Rawhide), creating an identical commit in the branch:
git merge rawhide
Push the changes to the server:
git push
Build the package:
fedpkg build
If there is another branch to work with repeat To switch to a branch and import and commit to each branch.
If everything goes well, it should queue up your branch for building, the package will cleanly build, and you’re done!
If it fails to build, the build system will send you an email to report the failure and show you to the logs. Commit any needed changes to git, bump the SPEC release number, and request a new build.
Entregar Paquete como Actualización en Bodhi
El sistema de actualización de Fedora llamado Bodhi se utiliza para enviar actualizaciones, clasificar paquetes, etc. Usted no necesita envíar actualizaciones para Rawhide (principal) manualmente porque estas son creadas automáticamente para usted cuando la compilación se completa. Para las otras ramas, debe enviar manualmente las actualizaciones de todas las construcciones que desee hacer disponibles para los usuarios.
Puede enviar una actualización usando Bodhi por medio de la línea de comandos usando esto en cada rama:
fedpkg update
It is often easier to complete builds for all your branches and then push a single update using the Bodhi web interface. Bodhi is smart enough to split your update into individual updates, one for each Fedora release branch.
You can also select multiple builds from different packages to include in a single update using the web interface. This is useful when you would like to push linked builds, for example: an application package and its dependencies that are necessary for it to run correctly.
Please see the Package Update Guide for more details.
Hacer que el paquete esté disponible en archivos "comps"
Si es apropiado para el paquete, hágalo disponible en archivos "comps" de modo que pueda ser seleccionado durante la instalación e incluido en las operaciones del grupo de paquetes dnf. Vea https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups?rd=PackageMaintainers/CompsXml[Como usar y editar comps.xml para grupos de paquete} para más información.
Atento a las actualizaciones
Fedora tiene una infraestructura disponible para monitorizar nuevas versiones del desarrollador del software que está empaquetando. Vea más detalles en Monitorizar Versiones del Desarrollador.
Want to help? Learn how to contribute to Fedora Docs ›