Jak przenosić użytkowników PPA z jednego PPA do drugiego?

8

Muszę przenieść istniejących użytkowników z jednej umowy PPA do innej umowy PPA, więc jest to pytanie, jak zautomatyzować przejście bez jak najmniejszego wpływu na użytkowników.

Dokładniej:

Mam umowy PPA dla PHP 5.5 i PHP 5.6, które używają starego pakietu PHP, który był używany przed Xenialem i mają całkiem sporo użytkowników.

Teraz stworzyłem nowy PPA, który zawiera PHP 5.5, PHP 5.6 i PHP 7.0 i chciałbym, aby użytkownicy starych PPA przełączyli się na ten nowy PPA. Mam kilka pomysłów, jak to zrobić, ale chciałbym uzyskać więcej informacji od społeczności AskUbuntu.

Podziel się swoimi przemyśleniami poprzez komentarze, edytuj poniższe odpowiedzi lub dodaj własne sugestie.

php ppa

— oerdnj
źródło

Ładne odpowiedzi ...

— simhumileco

3

Opcja 3 - Automatycznie dodaj nowy PPA

To jest jak 2, ale php5-commonautomatycznie doda nowy PPA, więc nowe pakiety będą dostępne po następnym apt-get updateuruchomieniu. Opcjonalnie może pojawić się pytanie Debconf, czy użytkownicy chcą dodawać PPA automatycznie, czy zrobią to sami.

Plusy:
1. Jedno pojedyncze repozytorium do obsługi
2. Bez automatycznego przejścia
3. Użytkownicy mogą przygotować plan przejścia
4. Pakiety są gotowe do zainstalowania od razu
5. Dodanie PPA z tej samej przestrzeni nazw może działać bezbłędnie
Cons:
1. Niektórzy użytkownicy przegapią ogłoszenie bez względu na to, jak bardzo się starasz
2. Automatyczne dodanie dodatkowego PPA wydaje się być zagrożeniem bezpieczeństwa
3. Dodanie dodatkowego PPA z innej przestrzeni nazw wymaga upuszczenia dodatkowych kluczy GPG, /etc/apt/trusted.gpg.d/co również wydaje się stanowić zagrożenie bezpieczeństwa

— oerdnj
źródło

Jest php-ppapakiet w starym ppa:ondrej/php5i ppa:ondrej/php5-5.6, więc można spróbować go już.

— oerdnj

Nie widzę ryzyka związanego z bezpieczeństwem dodania ppa (albo ci ufają i wszystko jest w porządku, albo nie, a potem nie powinni używać twoich pakietów na początku)?

— JanC

@JanC Dziękuję za opinię. Nadal byłbym niespokojny, gdyby pakiety dodawały dodatkowe PPA bez uprzedniego pytania, ale już zaimplementowałem pytanie debconf, więc myślę, że powinno być w porządku.

— oerdnj

Tak, oczywiście uprzedzenie użytkowników i / lub kiedy to nastąpi, a także udokumentowanie ich w pliku CHANGES lub innym, jest dobrym pomysłem.

— JanC

BTW: może w pewnym momencie chcesz również przeprowadzać regularne przebudowy bez zmian z przyrostowymi numerami wersji w starych PPA, aby ci, którzy ignorują zmianę PPA, otrzymywali regularne przypomnienia z debconf… :)

— JanC

2

Opcja 2 - Stwórz plan amortyzacji i wyraźnie poinformuj użytkowników

Plusy:
1. Jedno pojedyncze repozytorium do obsługi
2. Bez automatycznego przejścia
3. Użytkownicy mogą przygotować plan przejścia
Cons:
1. Niektórzy użytkownicy przegapią ogłoszenie bez względu na to, jak bardzo się starasz
2. Będą ludzie, którzy powiedzą: „Proszę, nie rób tego”
3. Bez automatycznego przejścia

— oerdnj
źródło

1

Opcja 1 - Nic nie rób

Plusy:
1. Użytkownicy są zadowoleni
Cons:
1. Każdy zduplikowany pakiet źródłowy musi mieć dwie wersje skryptu kompilacji
2. Przeciążony i niezadowolony opiekun PPA

— oerdnj
źródło

1

Opcja 4 - w pełni zautomatyzowane przejście

To jest jak opcja 3, ale dodaje fałszywe pakiety, które zastąpią stare php5*i wyciągną nowephp5.6*

Plusy (w tym Plusy z Opcji 3):
1. Jeśli wszystko działa zgodnie z oczekiwaniami, może to być najlepsza opcja, ponieważ użytkownicy będą mieli nowe pakiety bez żadnej pracy po swojej stronie
Minusy (obejmuje minusy z Opcji 3):
1. Przełącznik usunie zmiany, które ludzie wprowadzili do starych plików konfiguracyjnych, lub przejście będzie wymagać skomplikowanych skryptów opiekuna, aby przenieść starą konfigurację do nowych lokalizacji
2. Pakiet fikcyjny będzie musiał przeprowadzić co najmniej pewną konfigurację w celu ustawienia gniazda FPM i starych nazw, aby nie naruszyć zgodności ze starymi konfiguracjami (użyj aktualizacji-alternatyw, aby ustawić, /usr/bin/php5aby wskazać /usr/bin/php5.6)

— oerdnj
źródło