On Sun, Aug 26, 2007 at 10:28:01PM -0500, Mario Oyorzabal Salgado wrote: > Luis Rodrigo Gallardo Cruz escribió: > > > > Las indicaciones de que un paquete ha sido eliminado *no* se añaden > > como bugs al paquete. > > > > Pues hay un paquete que en una ocasión si vi la referencia de que lo hiban a > remover, por ejemplo eaccelerator, el cual hicieron la referencia sobre la > licencia y despúes fue removido, por eso crei que tal ves hicieron lo mismo con > vlc, que levantaran un ticket sobre algo incongruente antes de eliminarlo. A veces queda en el BTS la referencia de porque se elimina. Por ejemplo, si el motivo es un bug grave que no ha sido corregido en mucho tiempo, a menudo ese bug tendrá el registro de alguien diciendo "debido a este problema voy a pedir que eliminen el paquete". Pero la petición en sí se hace vía un bug a ftp.debian.org. Además, hay dos "clases" de eliminación. La que mencioné arriba es cuando un paquete definitivamente se elimina del archivo. En ese caso, primero sale de unstable y, cuando no quedan dependencias a él, sale automáticamente de testing. Otro caso es cuando un paquete solamente es eliminado de testing (como vlc) Esto ocurre cuando no es que el paquete sea inmantenible, pero sí no es de suficiente calidad como para ser candidato a estable. Estas eliminaciones se procesan por otro camino, mediante una petición al equipo de liberación. En cualquiera de los dos casos, el registro confiable es el que queda en el PTS <http://packages.qa.debian.org/>. > > > > En ese directorio vas a encontrar *todas* las versiones del paquete, > > de cualquier distribución en que están disponibles y sin indicación de > > a qué distribución pertenecen. > > > > los paquetes mediante un archivo .dsc, mencionan > a que rama pertenecen si son i386 u otra, o cuando le anexan +etch o +sarge, Estas confundiendo varios conceptos, creo. i386, alpha, sparc, etc son *arquitecturas*. (Casi) todos los paquetes tienen la misma versión en cada una para *todas* las ramas. stable, testing, unstable son *ramas*. Cada paquete puede tener distintas versiones en cada rama. Para un paquete dado, sus versiones *siempre* cumplen que stable <= testing <= unstable. En el caso normal, los paquetes se suben a unstable. Si son suficientemente buenos pasan a testing. Cuando testing se libera se convierte en stable. Debido a esto, casi todos los paquetes en el campo 'rama de destino' dicen 'unstable'. A veces es necesario subir un paquete destinado a una rama en particular sin pasar por todo el proceso. Por ejemplo, cuando hay que liberar una actualización de seguridad para un paquete en stable. En este caso, hay que hacer "trampitas" con el numero de versión, para asegurarse que se sigue cumpliendo la desigualdad entre los números mencionada arriba. Aquí es cuando ves esas versiones con un sufijo '+etch1' o cosas así. Por último, los mirrors están organizados a forma de ahorrar espacio. Cuando varias ramas tienen la misma versión de un paquete, todas apuntan a la misma copia del .deb Por eso decía que si te asomas en el mirror (en pool/v/vlc/ por ejemplo) no vas a saber para qué ramas hay paquetes, por que ahí están los .deb pero no las indicaciones de 'a qué rama pertenece esa versión'. Esas están en otro lado (en el archivo Packages de la rama, unos cuantos directorios arriba en el mirror, por si te interesa). -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
Attachment:
signature.asc
Description: Digital signature