From Fedora Project Wiki
No edit summary
No edit summary
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
{{lang|en|es|zh-cn|page=How to remove a package at end of life}}
{{lang|en|es|page=How to remove a package at end of life}}


Cuando un paquete llega al final de su vida útil, el siguiente procedimiento le permitirá a otras personas - y los procesos automatizados! - Saber tanto y no se esperan más lanzamientos, y por qué se quitó. El proceso es simple.
Cuando un paquete llega al final de su vida útil, el siguiente procedimiento le permitirá a otras personas - y los procesos automatizados! - Saber tanto y no se esperan más lanzamientos, y por qué se quitó. Este proceso se llama "retiro".


== Proceso ==
== Procedimiento ==
{{admon/warning|Retire sólo en las ramas de desarrollo y/o EPEL!|No retire paquetes en otras ramas aparte de Branched (hasta la [[Schedule|Congelación de funcionalidades]]), Rawhide (master) y EPEL (el5, el6, epel7).
Cuando necesite añadir paquetes desde EPEL a cualquier release RHEL, retirelo únicamente una vez el paquete haya sido publicado en esa versión RHEL.}}


Please execute the following steps in the order indicated.
Ejecute los pasos en el orden indicado:


# Asegúrese de que el paquete es obsoleto / Proporcionado por algo bien'' 'si''' está siendo reemplazada, ver  [[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages|Cambio de nombre/sustitución Directrices]]. Si no es así, continúe con el siguiente paso.
=== RPM ===
# Ejecutar <code>fedpkg retire MSG </code>. Esto eliminará de forma recursiva todos los archivos, a continuación, añadir un <code>dead.package</code> a git y retirar el paquete en el package DB (requiere fedpkg 1.13 o posterior). Esto debe hacerse para <code>maestro</code> y, a veces la liberación ramificado si aún no ha dado a conocer ('' 'No''' hacer esto para las versiones de Fedora liberados ya que no hay manera de quitar el paquete de extremo sistemas del usuario). El parámetro MSG es un mensaje que debe explicar brevemente en que este paquete fue ('paquete obsoleto en bar', 'renombrado como Bar', o similar) y se escribirá en el archivo dead.package.
Si el paquete va a ser reemplazado por algún otro paquete, asegúrese de que las etiquetas "Obsoletes/Provides" han sido establecidas adecuadamente en el nuevo paquete.
Vea[[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages|Renaming/Replacing Guidelines]].
 
=== GIT ===
Ejecute <code>fedpkg retire DESCRIPCIÓN</code> en todas las ramas que necesiten ser retiradas, empezando por la más antigua (p.ej, retire en f22 antes que en master)
 
==== Observaciones ====
* La <code>DESCRIPCIÓN</code> debe explicar por qué el paquete está siendo retirado. Por ejemplo:
** <code>Obsoleted by bar</code>
** <code>Renamed to bar</code>
* El comando eliminará todos los ficheros de la rama, añadirá un fichero llamado <code>dead.package</code> conteniendo la descripción, y subirá los cambios. A partir de fedpkg 1.13, también retirará el paquete de la base de datos de paquetes.
* <code>git rm</code> todos los ficheros en las otras ramas '''sólo si''' hay factores especiales a considerar, como problemas de licencia, o paquetes siendo completamente eliminados de Fedora.
* Si retira en master antes que en las ramas anteriores, simplemente continué con las ramas antiguas. Funcionará igual, pero bloqueará el paquete en más etiquetas de Koji.
 
=== Package DB ===
Asegúrese de que el paquete está marcado como "retirado" en [https://admin.fedoraproject.org/pkgdb the la base de datos de paquetes]. Debería ocurrir automáticamente a partir de fedpkg 1.13 si proporciona sus credenciales FAS. Si falla, puede hacerlo manualmente con el siguiente comando:
    pkgdb-cli orphan --retire PACKAGENAME master
 
==== Observaciones ====
* Una vez el paquete sea retirado de la abse de datos, no podrá hacer commits en GIT. Por tanto, limpie GIT primero.
* Cambie <code>master</code> por la correspondiente rama
* Empiece con la rama más antigua
 
=== Comps ===
Elimine el paquete de [[How_to_use_and_edit_comps.xml_for_package_groups| comps]] si aparece ahí.
 
=== Spins ===
Elimine el paquete de cualquier [https://fedorahosted.org/spin-kickstarts/ spin kickstart file]
    git clone ssh://git.fedorahosted.org/git/spin-kickstarts.git
 
=== Upstream Release Monitoring ===
Elimine el paquete de [[Upstream_release_monitoring]] si aparece ahí.
 
=== Koji ===
Para evitar que un paquete retirado sea subido a los mirrors, debe ser bloqueado. Normalmente esto ocurre durante automáticamente, pero si no, abra un ticket para [https://fedorahosted.org/rel-eng/newticket ticket] rel-eng (componente <code>koji</code>) mencionando el nombre del paquete y la rama donde debe ser bloqueado.
 
==== Observaciones ====
* Espere suficiente tiempo antes de crear el ticket.
* Use un único ticket para todos los paquetes retirados a la vez en lugar de uno por paquete.
* Compruebe si el paquete ha sido bloqueado en koji. Por ejemplo, para el paquete <code>curry</code> debe haber una entrada con <code>[BLOCKED]</code> para cada rama donde el paquete fue retirado. Es suficiente con haber sido retirado en una etiqueta más antigua, ya que por herencia se bloqueará en etiquetas más recientes:


# <code>git rm</code> all files in the other branches '''only if''' there are special factors at work, like licensing issues, or package being removed completely from Fedora.
# Remove the package from [[How_to_use_and_edit_comps.xml_for_package_groups| comps]]  if it is listed.
# Check for and remove the package from any spins kickstarts files: http://git.fedorahosted.org/git/spin-kickstarts.git
# Not necessary with fedpkg 1.13 or newer: Do '''not''' execute this step if you have not already completed steps 2 and 3, otherwise you will have to ask a [[Provenpackager policy|provenpackager]] to perform those steps for you. Mark the package as "retired" in [https://admin.fedoraproject.org/pkgdb the package database system]: log in with your FAS credentials, go to the page for your package, and click the '''Retire package''' button for each branch on which you are retiring the package.
# If the package was registered on [[Upstream_release_monitoring]], remove it from that page
# File a [https://fedorahosted.org/rel-eng/newticket ticket] for rel-eng (component <code>koji</code>) asking the package (or packages if there are many) to be blocked from the appropriate collections in which it is retired. You can mention several packages in one ticket. (There is a experimental service that takes care of this, therefore please only create a ticket if the package is not blocked in koji five minutes after it has been retired in package DB). Check whether it is blocked with koji, e.g. for the package <code>curry</code> there should the a entry with <code>[BLOCKED]</code> for each branch the package was retired in:
<pre>
<pre>
$ koji list-pkgs  --show-blocked --tag f21 --package curry                               
$ koji list-pkgs  --show-blocked --tag f21 --package curry                               
Line 24: Line 59:


== EPEL ==
== EPEL ==
Note that you can use this process for EPEL as well with a few differences:
Este proceso puede usarse en EPEL, con una diferencia:
 
* Puede eliminar el paquete de EPEL haya sido o no publicado.


* You can remove the package from any EPEL branch whether or not it has been released.
Por ejemplo, si su paquete ha sido añadido a la release de base RHEL-6.4, siga los mismos pasos pero use la rama <code>el6</code> branch en lugar de <code>master</code>.
* The component for the rel-eng ticket is <code>epel</code> rather than <code>koji</code>.


For example, if your package has been added to base RHEL in RHEL-6.4 then perform the steps above but use the <code>el6</code> branch instead of <code>master</code>.  When you open your rel-eng ticket to have the package blocked, use component <code>epel</code> instead of <code>koji</code>.
== Volver a activar el paquete ==
Vea [[Orphaned_package_that_need_new_maintainers]]


[[Category:Package Maintainers]]
[[Category:Package Maintainers]]
[[Category:Packaging guidelines]]

Latest revision as of 21:18, 17 October 2016

Cuando un paquete llega al final de su vida útil, el siguiente procedimiento le permitirá a otras personas - y los procesos automatizados! - Saber tanto y no se esperan más lanzamientos, y por qué se quitó. Este proceso se llama "retiro".

Procedimiento

Warning.png
Retire sólo en las ramas de desarrollo y/o EPEL!
No retire paquetes en otras ramas aparte de Branched (hasta la Congelación de funcionalidades), Rawhide (master) y EPEL (el5, el6, epel7). Cuando necesite añadir paquetes desde EPEL a cualquier release RHEL, retirelo únicamente una vez el paquete haya sido publicado en esa versión RHEL.

Ejecute los pasos en el orden indicado:

RPM

Si el paquete va a ser reemplazado por algún otro paquete, asegúrese de que las etiquetas "Obsoletes/Provides" han sido establecidas adecuadamente en el nuevo paquete. VeaRenaming/Replacing Guidelines.

GIT

Ejecute fedpkg retire DESCRIPCIÓN en todas las ramas que necesiten ser retiradas, empezando por la más antigua (p.ej, retire en f22 antes que en master)

Observaciones

  • La DESCRIPCIÓN debe explicar por qué el paquete está siendo retirado. Por ejemplo:
    • Obsoleted by bar
    • Renamed to bar
  • El comando eliminará todos los ficheros de la rama, añadirá un fichero llamado dead.package conteniendo la descripción, y subirá los cambios. A partir de fedpkg 1.13, también retirará el paquete de la base de datos de paquetes.
  • git rm todos los ficheros en las otras ramas sólo si hay factores especiales a considerar, como problemas de licencia, o paquetes siendo completamente eliminados de Fedora.
  • Si retira en master antes que en las ramas anteriores, simplemente continué con las ramas antiguas. Funcionará igual, pero bloqueará el paquete en más etiquetas de Koji.

Package DB

Asegúrese de que el paquete está marcado como "retirado" en the la base de datos de paquetes. Debería ocurrir automáticamente a partir de fedpkg 1.13 si proporciona sus credenciales FAS. Si falla, puede hacerlo manualmente con el siguiente comando:

   pkgdb-cli orphan --retire PACKAGENAME master

Observaciones

  • Una vez el paquete sea retirado de la abse de datos, no podrá hacer commits en GIT. Por tanto, limpie GIT primero.
  • Cambie master por la correspondiente rama
  • Empiece con la rama más antigua

Comps

Elimine el paquete de comps si aparece ahí.

Spins

Elimine el paquete de cualquier spin kickstart file

   git clone ssh://git.fedorahosted.org/git/spin-kickstarts.git

Upstream Release Monitoring

Elimine el paquete de Upstream_release_monitoring si aparece ahí.

Koji

Para evitar que un paquete retirado sea subido a los mirrors, debe ser bloqueado. Normalmente esto ocurre durante automáticamente, pero si no, abra un ticket para ticket rel-eng (componente koji) mencionando el nombre del paquete y la rama donde debe ser bloqueado.

Observaciones

  • Espere suficiente tiempo antes de crear el ticket.
  • Use un único ticket para todos los paquetes retirados a la vez en lugar de uno por paquete.
  • Compruebe si el paquete ha sido bloqueado en koji. Por ejemplo, para el paquete curry debe haber una entrada con [BLOCKED] para cada rama donde el paquete fue retirado. Es suficiente con haber sido retirado en una etiqueta más antigua, ya que por herencia se bloqueará en etiquetas más recientes:
$ koji list-pkgs  --show-blocked --tag f21 --package curry                               
Package                 Tag                     Extra Arches     Owner          
----------------------- ----------------------- ---------------- ---------------
curry                   f20                                      gemi            [BLOCKED]

EPEL

Este proceso puede usarse en EPEL, con una diferencia:

  • Puede eliminar el paquete de EPEL haya sido o no publicado.

Por ejemplo, si su paquete ha sido añadido a la release de base RHEL-6.4, siga los mismos pasos pero use la rama el6 branch en lugar de master.

Volver a activar el paquete

Vea Orphaned_package_that_need_new_maintainers