Come trasferire utenti PPA da un PPA a un altro?

8

Devo trasferire utenti esistenti da uno o più PPA a diversi PPA, quindi questa è una domanda su come automatizzare la transizione senza il minor impatto possibile sugli utenti.

Più precisamente:

Ho PPA per PHP 5.5 e PHP 5.6 che usano un packaging PHP vecchio stile che era usato pre-Xenial e hanno un sacco di utenti.

Ora ho realizzato un nuovo PPA che include PHP 5.5, PHP 5.6 e PHP 7.0 e vorrei che gli utenti dei vecchi PPA passassero a questo nuovo PPA. Ho un paio di idee su come fare questo generale, ma vorrei avere più input dalla comunità AskUbuntu.

Contribuisci con i tuoi pensieri tramite commenti, modifica diretta alle risposte di seguito o aggiungi il tuo suggerimento.

php ppa

— oerdnj
fonte

Belle risposte ...

— simhumileco,

3

Opzione 3: aggiungere automaticamente il nuovo PPA

Questo è come 2, ma php5-commonaggiungerebbe automaticamente il nuovo PPA, quindi i nuovi pacchetti sarebbero disponibili dopo la prossima apt-get updateesecuzione. Opzionalmente potrebbe esserci una domanda Debconf se gli utenti vogliono che il PPA venga aggiunto automaticamente o lo faranno da soli.

Professionisti:
1. Un unico repository da gestire
2. Nessuna transizione automatica
3. Gli utenti possono preparare il loro piano di transizione
4. I pacchetti sono pronti per essere installati immediatamente
5. L'aggiunta di PPA dallo stesso spazio dei nomi potrebbe funzionare in modo impeccabile
Contro:
1. Ad alcuni utenti mancherà l'annuncio, non importa quanto duramente ci provi
2. L'aggiunta di ulteriori PPA sembra automaticamente un rischio per la sicurezza
3. L'aggiunta di ulteriore PPA da uno spazio dei nomi diverso richiede l'inserimento di chiavi GPG aggiuntive /etc/apt/trusted.gpg.d/e questo sembra anche un rischio per la sicurezza

— oerdnj
fonte

C'è un php-ppapacchetto nel vecchio ppa:ondrej/php5e ppa:ondrej/php5-5.6, quindi puoi già provarlo.

— oerdnj,

Non vedo il rischio per la sicurezza di aggiungere un ppa (o si fidano di te e tutto va bene, oppure no e quindi non dovrebbero usare i tuoi pacchetti per cominciare)?

— JanC

@JanC Grazie per il feedback. Ancora mi metterebbe a disagio se i pacchetti aggiungessero ulteriori PPA senza prima chiedere, ma ho già implementato una domanda debconf per questo, quindi penso che dovrebbe essere ok.

— oerdnj,

Sì, ovviamente avvisare i tuoi utenti in anticipo e / o quando ciò accade, oltre a documentarlo in un file CHANGES o simili, è una buona idea.

— JanC,

A proposito: forse a un certo punto vuoi anche fare ricostruzioni regolari senza modifiche con numeri di versione incrementali incorporati nei vecchi PPA, in modo che quelli che ignorano la modifica PPA ricevano regolari promemoria da debconf ... :)

— JanC

2

Opzione 2: creare un piano di ammortamento e informare gli utenti in modo prominente

Professionisti:
1. Un unico repository da gestire
2. Nessuna transizione automatica
3. Gli utenti possono preparare il loro piano di transizione
Contro:
1. Ad alcuni utenti mancherà l'annuncio, non importa quanto duramente ci provi
2. Ci saranno persone che diranno: "Per favore, non farlo"
3. Nessuna transizione automatica

— oerdnj
fonte

1

Opzione 1 - Non fare nulla

Professionisti:
1. Gli utenti sono felici
Contro:
1. Ogni pacchetto sorgente duplicato deve avere due versioni dello script di compilazione
2. Manutentore PPA sovraccarico e infelice

— oerdnj
fonte

1

Opzione 4 - Transizione completamente automatizzata

È come l'opzione 3, ma aggiunge pacchetti fittizi che sostituiranno il vecchio php5*e tireranno il nuovophp5.6*

Pro (include Pro dall'opzione 3):
1. Se tutto funziona come previsto, potrebbe essere l'opzione migliore, poiché gli utenti avranno i nuovi pacchetti senza alcun lavoro al loro fianco
Contro (include contro dall'opzione 3):
1. Lo switch rimuoverà le modifiche apportate dagli utenti ai vecchi file di configurazione o la transizione richiederà alcuni script manutentori complessi per spostare la vecchia configurazione nelle nuove posizioni
2. Il pacchetto fittizio dovrà contenere almeno alcune configurazioni per l'installazione del socket FPM e dei vecchi nomi per non interrompere la compatibilità con le vecchie configurazioni (utilizzare le opzioni di aggiornamento per impostare il /usr/bin/php5punto su cui puntare /usr/bin/php5.6)

— oerdnj
fonte