¿Cómo hacer la transición de los usuarios de PPA de un PPA a otro?

8

Necesito hacer la transición de los usuarios existentes de un PPA (s) a un PPA diferente, por lo que esta es una pregunta sobre cómo automatizar la transición sin el menor impacto posible en los usuarios.

Más precisamente:

Tengo PPA para PHP 5.5 y PHP 5.6 que usan empaques PHP de estilo antiguo que se usaron antes de Xenial y tienen muchos usuarios.

Ahora hice un nuevo PPA que incluye PHP 5.5, PHP 5.6 y PHP 7.0 y quisiera que los usuarios de viejos PPA cambiaran a este nuevo PPA. Tengo un par de ideas sobre cómo hacer esto en general, pero me gustaría tener más información de la comunidad AskUbuntu.

Contribuya con sus pensamientos a través de comentarios, ediciones directas a las respuestas a continuación o agregue su propia sugerencia.

php ppa oerdnj
fuente
Buenas respuestas ...
simhumileco

Respuestas:

3

Opción 3: agregar automáticamente el nuevo PPA

Esto es como 2, pero php5-commonagregaría automáticamente el nuevo PPA, por lo que los nuevos paquetes estarán disponibles después de la próxima apt-get updateejecución. Opcionalmente, podría haber una pregunta de Debconf si los usuarios desean que se agregue el PPA automáticamente o si lo harán ellos mismos.

  • Pros:
    1. Un único repositorio para manejar
    2. Sin transición automática
    3. Los usuarios pueden preparar su plan de transición.
    4. Los paquetes están listos para ser instalados de inmediato.
    5. Agregar PPA desde el mismo espacio de nombres podría funcionar perfectamente
  • Contras:
    1. Algunos usuarios perderán el anuncio sin importar cuánto lo intenten
    2. Agregar PPA adicional automáticamente parece un riesgo de seguridad
    3. Agregar PPA adicional desde diferentes espacios de nombres necesita colocar claves GPG adicionales /etc/apt/trusted.gpg.d/y eso también parece un riesgo de seguridad
oerdnj
fuente
Hay un php-ppapaquete en el viejo ppa:ondrej/php5y ppa:ondrej/php5-5.6, por lo que ya puedes probarlo.
Oerdnj
No veo el riesgo de seguridad de agregar un ppa (o confían en ti y todo está bien, o no lo hacen y, para empezar, no deberían estar usando tus paquetes).
JanC
@ Jan Gracias por los comentarios. Aún así me pondría incómodo si los paquetes agregaran PPA adicionales sin preguntar primero, pero ya implementé una pregunta de debconf para eso, así que creo que debería estar bien.
oerdnj
Sí, por supuesto, es una buena idea advertir a sus usuarios de antemano y / o cuando sucede, así como documentarlo en un archivo de CAMBIOS o similar.
JanC
Por cierto: tal vez en algún momento también desee realizar reconstrucciones regulares sin cambios con números de versión incorporados incrementales en los antiguos PPA, para que aquellos que ignoran el cambio de PPA reciban recordatorios regulares de debconf ... :)
JanC
2

Opción 2: haga un plan de desaprobación e informe a los usuarios de manera destacada

  • Pros:
    1. Un único repositorio para manejar
    2. Sin transición automática
    3. Los usuarios pueden preparar su plan de transición.
  • Contras:
    1. Algunos usuarios perderán el anuncio sin importar cuánto lo intenten
    2. Habrá gente que dirá: "Por favor, no hagas eso"
    3. Sin transición automática
oerdnj
fuente
1

Opción 1: no hacer nada

  • Pros:
    1. Los usuarios son felices
  • Contras:
    1. Cada paquete fuente duplicado debe tener dos versiones del script de compilación
    2. Mantener PPA sobrecargado e infeliz
oerdnj
fuente
1

Opción 4: transición totalmente automatizada

Esto es como la Opción 3, pero agrega paquetes ficticios que reemplazarán lo antiguo php5*y extraerán lo nuevophp5.6*

  • Pros (incluye profesionales de la opción 3):
    1. Si todo funciona como se esperaba, podría ser la mejor opción, ya que los usuarios tendrán los nuevos paquetes sin ningún trabajo a su lado.
  • Contras (incluye Contras de la Opción 3):
    1. El conmutador eliminará los cambios que la gente ha realizado en los archivos de configuración antiguos o la transición necesitará algunos scripts de mantenimiento complejos para barajar la configuración anterior a las nuevas ubicaciones.
    2. El paquete ficticio tendrá que llevar al menos alguna configuración para configurar el socket FPM y los nombres antiguos para no romper la compatibilidad con las configuraciones antiguas (use las alternativas de actualización a la configuración /usr/bin/php5para apuntar /usr/bin/php5.6)
oerdnj
fuente