Чому попередні версії пакунків Debian зникають у сховищах пакетів? (дуже актуально для конфігурації системи, керованої версіями)

Сценарій: у конфігурації системи, керованої версіями, заснованої на Лялькові, шеф-кухарі тощо, потрібно відтворити певний стан системи. Це робиться, чітко вказавши версії системного пакету.

Нещодавно ми зіткнулися з проблемою, коли в сховищах Debian відсутні деякі версії пакетів. Один приклад: Пакет "патч" був потрібний у версії 2.7.5-1 + deb9u1, але був доступний лише 2.7.5-1 + deb9u2. Ще один, ще більш суворий приклад: "потрібен" linux-headers-4.9.0-9-common "(завдяки встановленому асоційованому ядру) і доступний лише" linux-headers-4.9.0-11-common ".

Це унеможливлює відтворення певного стану системи.

Наведені вище пакети - лише приклади (з якими я насправді стикався). Мені цікаво зрозуміти та вирішити загальну проблему.

Яка ідея цих оновлень, «зникаючих» пакетів та версій пакетів?

Де я можу отримати попередні версії (не дуже старі версії, але версії, що мають пару тижнів) пакетів Debian? Повинно бути можливим автоматизувати процес установки загальним способом.

debian package-management

— Flo
джерело

Дещо залежить від програмного забезпечення, яке використовується для налаштування сховища. Reprepro, iirc, дозволяє лише одну версію кожного пакету

— muru

stableзалишається послідовним, принаймні до наступного випуску пункту. стабільні оновлення, тестування та нестабільність містять лише останню версію будь-якого пакета. Щодо іншого, вам доведеться подивитися на archive.debian.org (або snapshot.debian.org, як згадується у відповіді SK)

— cas

Чи є причина, що у вас не працює власне репо, на якому ви можете контролювати політику заміни та версії штифтів (що матиме перевагу робити місцеві автоматичні встановлення в майбутньому)?

— Ерік Тауерс

Нове linuxім'я pkg - виняток: загалом, пакети Debian stable діють під тим самим іменем пакета і змінюють лише номер версії. linux-image-amd64ніколи не змінює ім'я і завжди залежить від останнього linux-image-4.9.0-*. Нове linux-image-4.9.0-*ім'я pkg позначає несумісні зміни ABI ядра, необхідні для підтримки деяких помилок і дозволяє вирішити необхідну перекомпіляцію вбудованих модулів (dkms тощо). Аналогічно для linux-headers-*.

— ignis

Яка ідея цих оновлень apt-get changelog packagename

— ignis

Відповіді:

Можливість відтворення конкретної установки до точної версії - це ваша вимога, а не Debian.

Debian підтримує лише одну версію кожного бінарного пакету в будь-якому випуску; протилежне тому полягає в тому, що велика увага приділяється тому, щоб оновлення пакунків у будь-якому даному випуску не вносили регресій, а коли така обережність неможлива, документально підтверджувати цей факт. Збереження декількох версій даного пакету лише збільшить навантаження на підтримку та вимоги до тестування: наприклад, обслуговуючим пакетам доведеться протестувати оновлені пакети на всіх доступних версіях бібліотек, які вони використовують замість лише підтримуваних на даний момент версій ... Пакети оновлюються в стабільному випуску лише тоді, коли це дійсно необхідно, тобтощоб виправити серйозну помилку (включаючи проблеми безпеки). У випадку ядра це іноді означає, що ядро ABI змінюється, а ім'я пакета змінюється в результаті цього (щоб примусити перебудовувати залежні пакети); є мета-пакети , які ви можете тягнути в замість жорсткого кодування ЛПІ ( linux-image-amd64, linux-headers-amd64і т.д.).

Однак існує рішення для вашої ситуації: кожен опублікований джерело та двійковий пакет архівується на snapshot.debian.org . Створюючи версійну установку, ви можете вибрати відповідний знімок (наприклад, один із знімків вересня 2019 року ) і використовувати його як свою URL-адресу сховища:

deb https://snapshot.debian.org/archive/debian/20190930T084755Z/ buster main

Якщо ви все-таки покладаєтесь на це, будь ласка, використовуйте якесь кешоване дзеркало, наприклад Apt-Cacher NG . Це не тільки зменшить навантаження на сервер знімків, але й забезпечить локальну копію всіх необхідних пакетів.

(Ситуація щодо вихідних пакетів дещо складніша, і архіви несуть кілька версій деяких вихідних пакетів у даному випуску через залежність від ліцензування. Але це не актуально. Суворо кажучи, Debian пропонує декілька версій деяких бінарні файли в підтримуваних випусках: поточна версія в поточному випуску точки разом з будь-якими оновленнями в сховищах безпеки та сховищах оновлень; останні складаються в наступному випуску точки. Тому підтримка відтворюваної, керованої версією системи конфігурації неможлива без вдаючись до знімків, якщо ви оновлюєте його щоразу, коли робиться точковий випуск.)

— Стівен Кітт
джерело

Зауважте, що іноді доступні деякі попередні версії - apt-cache madison packagenameвідображатимуться всі версії, які aptможна побачити через налаштовані сховища.

— іваніван

(Будь ласка, не перевантажуйте сервери знімків / архівів, використовуючи їх без потреби, замість сусіднього дзеркала. Тому залиште своє звичайне дзеркало у своєму source.list з більш високим пріоритетом, ніж знімок, тому пакети, які ще доступні в ньому, можна отримати таким чином .)

— Пітер Кордес

Просто щоб переконатися, що я правильно зрозумів: На практиці йдеться не про версії, які я вказую під час встановлення пакетів (оскільки старі версії можуть бути недоступні), а про стан сховища пакетів (пакетів) пакетів, який я використовую. Отже, якщо я хочу "свіжий" Debian 9.8, мені потрібне сховище пакунків у такому самому стані (наприклад, знімок або сховище, яке я створив сам), і тоді, звичайно, правильний пакет Linux-header- * залишається доступним . Якщо я хочу перейти на Debian 9.9, я отримую сховище пакунків у відповідне стан і запускаю apt-get dist-upgrade. Це правильно?

— Flo

Так, це правильно.

— Стівен Кітт

@ Зауважте, що точкові релізи (як debian X.9 або X.8) призначені лише для завантажувальних iso, тому нові установки не завантажують багато пакетів. У сховищах немає різниці між будь-яким пунктом випуску, ви завжди отримуєте останній пакет.

— Брайам

Не відштовхуйтесь від серверів, які не знаходяться під вашим контролем, для відтворення певного стану системи. Навіть думав, що сервери Debian досить надійні, ви ніколи не знаєте, що може статися в майбутньому. Це особливо актуально для інших сховищ, які ви можете використовувати.

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

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

— Чарлстон
джерело

Хоча відповідь Стівена Кітта, безумовно, є одним із можливих рішень, я думаю, було б безпечніше зберігати власні копії необхідних пакетів.

Під час запису налаштувань системи обов'язково збережіть копії .debфайлів з-за /var/cache/apt/archives/. Ви також можете використовувати apt-get download.

Відновлюючи налаштування системи, ви повинні бути дуже суворими, aptщоб уникнути запуску потенційно небезпечних автоматичних дій.

Напевно, буде простіше використовувати dpkgбезпосередньо, щоб встановити саме те, що ви хочете.

— Стиг Хеммер
джерело

Ще кращим підходом до IMO було б використання локального кешу APT. Це дозволяє уникнути проблем у вашому третьому абзаці, а також уникає збору врожаю /var/cache/apt.

— Стівен Кітт

Є два варіанти цього - один - використовувати щось на зразок apt-дзеркала для клонування цілого репо, інший - завантажувати лише певні пакети та залежності . Потім зробіть знімок реж - наприклад, з btrfs як pkgs-20190501, а потім опублікуйте реплік знімка як репо. На час складання помістіть перетворений URL-репо (наприклад http://debmirror/pkgs-20190501/...) у source.list, потім запустіть apt-get update, apt-get install $ pkgs тощо.

— bain