Як перейти користувачів PPA з однієї PPA в іншу?

8

Мені потрібно перейти існуючих користувачів з однієї PPA до різних PPA, тому це питання, як автоматизувати перехід без мінімального впливу на користувачів.

Точніше:

У мене є PPA для PHP 5.5 та PHP 5.6, які використовують упаковку PHP у старому стилі, яка використовувалася до Xenial, і вони мають досить багато користувачів.

Тепер я створив новий PPA, що включає PHP 5.5, PHP 5.6 та PHP 7.0, і я б користувачі старих PPA перейшли на цей новий PPA. У мене є кілька ідей, як це зробити в цілому, але я хотів би отримати більше інформації від спільноти AskUbuntu.

Будь ласка, додавайте свої думки за допомогою коментарів, направляйте зміни на відповіді нижче або додайте власну пропозицію.

php ppa

— oerdnj
джерело

Приємні відповіді ...

— simhumileco

3

Варіант 3 - Автоматично додавати новий PPA

Це як 2, але php5-commonавтоматично додасть новий PPA, тому нові пакети будуть доступні після наступного apt-get updateзапуску. За бажанням може виникнути питання Debconf, чи бажають користувачі автоматично додавати PPA або вони це зроблять самі.

Плюси:
1. Одне єдине сховище для обробки
2. Немає автоматичного переходу
3. Користувачі можуть підготувати свій план переходу
4. Пакети готові до встановлення відразу
5. Додавання PPA з одного простору імен може працювати бездоганно
Мінуси:
1. Деякі користувачі пропустять оголошення, незалежно від того, наскільки ви намагаєтесь
2. Додавання додаткового PPA автоматично видається ризиком безпеки
3. Додавання додаткового PPA з різних просторів імен потребує скидання зайвих ключів GPG, /etc/apt/trusted.gpg.d/і це також здається ризиком для безпеки

— oerdnj
джерело

Там же php-ppaпакет в старому ppa:ondrej/php5і ppa:ondrej/php5-5.6, таким чином , ви можете спробувати це вже.

— oerdnj

Я не бачу ризику безпеки додати ppa (або вони вам довіряють, і все нормально, або вони не роблять, і тоді вони не повинні використовувати ваші пакунки для початку)?

— Janc

@JanC Дякую за відгук. Доки б мені було неприємно, якби пакети додавали додаткові PPA, не запитуючи спочатку, але я вже реалізував питання про дебюнф для цього, тому я думаю, що це повинно бути нормально.

— oerdnj

Так, звичайно попереджаючи своїх користувачів заздалегідь та / або коли це відбувається, а також документувати їх у файлі ЗМІНИ або подібному, є хорошою ідеєю.

— JanC

BTW: можливо, в якийсь момент ви також хочете робити регулярні перебудови без змін із наростаючими номерами версій у старих PPA, щоб ті, хто ігнорує зміну PPA, отримували регулярні нагадування від debconf… :)

— JanC

2

Варіант 2 - Скласти план анулювання та повідомити користувачів про це

Плюси:
1. Одне єдине сховище для обробки
2. Немає автоматичного переходу
3. Користувачі можуть підготувати свій план переходу
Мінуси:
1. Деякі користувачі пропустять оголошення, незалежно від того, наскільки ви намагаєтесь
2. Будуть люди, як скажуть: "Будь ласка, не робіть цього"
3. Немає автоматичного переходу

— oerdnj
джерело

1

Варіант 1 - Не робіть нічого

Плюси:
1. Користувачі задоволені
Мінуси:
1. Кожен повторюваний вихідний пакет повинен мати дві версії сценарію збірки
2. Перевантажений і нещасний обслуговувач PPA

— oerdnj
джерело

1

Варіант 4 - Повністю автоматизований перехід

Це як варіант 3, але додає фіктивні пакети, які замінять старі php5*та потягнуть новіphp5.6*

Плюси (включає плюси з варіанту 3):
1. Якщо все працює як очікувалося, це може бути найкращим варіантом, оскільки користувачі матимуть нові пакети без будь-якої роботи
Мінуси (включає мінуси з варіанту 3):
1. Комутатор видалить зміни, внесені людьми до старих файлів конфігурації, або для переходу знадобляться деякі складні сценарії технічного обслуговування, щоб перемістити стару конфігурацію на нові місця
2. Макетний пакет повинен мати принаймні деяку конфігурацію для установки FPM-сокета і старих імен, щоб не порушувати сумісність зі старими настройками (використовуйте оновлення-альтернативи для установки, /usr/bin/php5щоб вказати на /usr/bin/php5.6)

— oerdnj
джерело