LXF170:Поддержка дистрибутива в актуальном состоянии

Текущая версия на 02:43, 17 ноября 2018

[править] Поддержка пакетной базы дистрибутива в актуальном состоянии

Ан­д­рей По­но­ма­рен­ко и Вла­ди­мир Ру­ба­нов опи­сы­ва­ют комплексный подход к обновлению пакетов.

Основная деятельность разработчиков дистрибутивов Linux (мейнтейнеров) заключается глав­ным образом в объединении уже существующих различных свободных компонентов в еди­ный про­грамм­ный ком­плекс для решения задач пользователей. Основными примерами таких компонентов являются ядро, библиотеки, утилиты и пользовательские приложения. При этом в процессе интеграции нового компонента в систему у мейнтейнера, как правило, есть широкий выбор среди множества различных версий этого компонента – старые или новые, стабильные или экспериментальные, и т. д.

Выбор той или иной версии компонента зависит от поставленных целей конкретного дистрибутива. Уп­ро­щен­но – если дистрибутив предназначен для серверных станций, то выбор падает на старые стабильные версии программ, которые уже проверены временем. Если же дистрибутив предназначен для настольных компьютеров домашних пользователей, то выбирают бо­лее све­жие версии с мак­си­му­мом но­вых функ­ций. Но какая бы версия компонента ни была вы­брана, со временем его приходится обновлять для предоставления пользователям большей функциональности, либо для исправления ошибок и уязвимостей.

[править] Обновление пакетов

Главным условием при обновлении любого пакета в со­ста­ве кон­крет­но­го ди­ст­ри­бу­ти­ва является работоспособность этого па­кета после обновления, а так­же работоспособность остальных пакетов, связанных с данным. Имен­но из-за на­ли­чия за­ви­си­мо­стей об­нов­ление пакета пре­вра­ща­ет­ся в нетри­ви­аль­ную за­да­чу, решение которой при­хо­дит­ся раз­би­вать на несколько последовательных этапов. Сначала мейнтейнеру необ­хо­ди­мо узнать о появлении новой версии исходного кода компонента у его авторов (в апстриме – от анг­лий­ско­го upstream). Затем необходимо проанализировать изменения в исходном коде и адаптировать новую версию компонента к кон­крет­но­му ди­ст­ри­бу­ти­ву (это мо­жет вклю­чать как из­менения ко­да, так и до­ра­бот­ку спе­ци­фи­ка­ци­он­но­го фай­ла па­ке­та) с уче­том всех за­ви­си­мо­стей. При этом за­ви­си­мые ком­по­нен­ты и ком­понен­ты, от ко­то­рых за­ви­сит дан­ный, то­же, воз­мож­но, при­дет­ся ре­кур­сив­но об­нов­лять. Фи­наль­ным ша­гом яв­ля­ет­ся про­вер­ка ре­аль­ной ра­бо­то­спо­соб­но­сти об­нов­лен­но­го компонента, в ре­зуль­та­те ко­то­рой час­то при­хо­дит­ся воз­вра­щать­ся к пре­ды­ду­ще­му ша­гу.

Задача по обновлению пакетов значительно осложняется тем, что количе­ство пакетов в современных дистрибутивах достигает величины нескольких десятков тысяч, за­ви­си­мо­сти ме­ж­ду ними пе­ре­пле­те­ны в клу­бок, и на одного мейнтейнера может приходиться ответственность за несколько сотен пакетов. Для ор­ганиза­ции ра­бо­ты мейн­тейнера в та­ких усло­ви­ях необ­хо­ди­мы специальные автоматизированные инструменты.

[править] Виды зависимостей между пакетами

Зависимости между компонентами системы могут быть двух видов: прямые и обратные. Прямые зависимости – это все компоненты, необходимые данному. Обратные же зависимости – это за­ви­си­мые компоненты, которым требуется данный компонент.

Как бы­ло от­ме­че­но ранее, при обновлении какого-либо компонента, необходимо также обновить или адаптировать все его пря­мые и об­рат­ные зависимости.

Начинающие мейнтейнеры часто обращают внимание только на прямые зависимости, поскольку они непосредственно влияют на сборку их компонента, и, как правило, забывают о проверке обратных зависимостей. В результате этого сборка обратных зависимостей может быть нарушена, что может привести к частичной неработоспособности дистрибутива и, тем самым, серьезно помешать работе других мейнтейнеров.

[править] Совместимость пакетов

Сборка обратных зависимостей компонента может быть нарушена при его обновлении, если нарушается совместимость между ними. Совместимость бывает трех типов. Наиболее важным типом является совместимость на уровне исходных кодов, которая означает возможность взаимной пересборки компонентов без ошибок. Следующим типом является двоичная совместимость между компонентами, которая означает возможность работы одного компонента после обновления другого без пересборки и наоборот. И, наконец, различают функциональную совместимость, которая означает корректное се­ман­ти­че­­ское взаимодействие.

Немаловажным понятием также является обратная совместимость компонента. Вместо проверки совместимости между разными компонентами можно эквивалентно проверять совместимость между старыми и новыми версиями каж­дого из них. Например, обратная двоичная совместимость позволяет заменить компонент в системе на более новый без необходимости пересборки вышестоящего стека программ. Этим свойством часто пользуются мейнтейнеры для ускорения своей работы, так как порой количе­ство обратных зависимостей системных библиотек может быть очень большим, и их пересборка заняла бы слишком много времени.

[править] Анализ изменений в пакетах

Перед тем как интегрировать новую версию компонента в дистрибутив, мейнтейнеру необходимо убедиться, что ни один из трех типов совместимости не будет нарушен. Для этого он может использовать различные инструменты в зависимости от вида компонента.

Самым распространенным видом компонента в дистрибутивах Linux, имеющим обратные зависимости, являются библиотеки. Для проверки совместимости системных библиотек используют инструмент ABI Compliance Checker [1]. Данный инструмент проверяет только структурную совместимость, т. е. двоичную совместимость и совместимость на уровне исходных кодов. Функцио­нальную же совместимость мейнтейнер должен проверять либо с помощью встроенных тестов компонента или вручную. Инструмент проверяет изменения в заголовочных файлах библиотеки или, что эквивалентно, в debug-информации двоичных файлов библиотеки.

Для других видов компонентов может быть использован инструмент PkgDiff [2], который позволяет визуализировать и классифицировать изменения в новой версии компонента. На основе его отчета мейнтейнер может самостоятельно проанализировать совместимость изменений. Инструмент может сравнивать архивы с исходным кодом, а также двоичные RPM- или Deb- пакеты.

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

Обычно в конкретном дистрибутиве используется только часть внешних интерфейсов компонента. Такие интерфейсы называют активными, и только в них, по возможности, мейнтейнерам надо проверять изменения. Например, в некоторых библиотеках может использоваться только одна функция, и нет никакой необходимости проверять остальные. Однако определить активные и неактивные интерфейсы порой довольно сложно.

[править] Мониторинг апстрима

Задача обновления большого количе­ства компонентов значительно упрощается при наличии у дистрибутива специальных систем мониторинга активности апстрима. Такие системы периодиче­ски проверяют репозитории компонентов дистрибутива в апстриме и уведомляют мейнтейнеров о наличии новых версий. Система мониторинга в дистрибутиве Fedora [3] не только оповещает мейнтейнеров о новых версиях, но и сама заводит баги о необходимости обновления. Некоторые системы мониторинга могут также проводить анализ новых версий. Например, система мониторинга апстрима в дистрибутиве ROSA под названием Upstream Tracker [4] производит анализ обратной совместимости библиотек и вы­кла­ды­ва­ет отчеты в публичный доступ. По этой причине она востребована не только мейнтейнерами РОСЫ, но и мейнтейнерами других дистрибутивов, а также пользователями и авторами библиотек в апстриме.

[править] Слежение за другими дистрибутивами

Для раз­ра­бот­ки и под­дер­жания ак­ту­аль­но­сти ди­ст­ри­бу­ти­вов важ­но иметь све­жие вер­сии ком­понен­тов. Од­на­ко при этом нет необ­хо­ди­мо­сти иметь са­мые по­следние вер­сии из ап­ст­ри­ма, ко­то­рые мо­гут быть слиш­ком неста­биль­ны­ми. Здесь важ­но от­сле­жи­вать ис­поль­зо­вание раз­лич­ных вер­сий оп­ре­де­лен­но­го ком­понен­та кол­ле­га­ми – раз­ра­бот­чи­ка­ми дру­гих ди­ст­ри­бу­ти­вов, что косвен­но слу­жит по­ка­за­те­лем ста­биль­но­сти той или иной вер­сии. Для это­го необ­хо­ди­мо уметь сис­те­ма­ти­че­­ски сравнивать вер­сии про­грамм в сво­ем ди­ст­ри­бу­ти­ве с вер­сия­ми у кол­лег и оп­ре­де­лять уста­рев­шие. В ди­ст­ри­бу­ти­ве Mandriva, на­при­мер, ис­поль­зу­ют от­чет [5], в ко­то­ром про­из­во­дит­ся сравнение с вер­сия­ми па­ке­тов ди­ст­ри­бу­ти­ва Mageia. А в ди­ст­ри­бу­ти­ве ROSA ис­поль­зу­ет­ся ав­то­ма­ти­зи­ро­ван­ная сис­те­ма Updates Tracker [6], ко­то­рая не толь­ко про­из­во­дит сравнение с ди­ст­ри­бу­ти­ва­ми Mandriva и Mageia (до­бав­ление сле­жения за дру­ги­ми ди­ст­ри­бу­ти­ва­ми на­хо­дит­ся в про­цес­се), но и на­хо­дит по­следние вер­сии про­грамм в ори­ги­наль­ном ап­ст­ри­ме, по­зво­ляя ана­ли­зи­ро­вать ком­плекс­ную кар­ти­ну для при­ня­тия ре­шений о необ­хо­ди­мо­сти об­нов­ления тех или иных ком­понен­тов.

[править] Совместимость дистрибутивов

• Метамодернизм в позднем творчестве В.Г. Сорокина
• ЛитРПГ - последняя отрыжка постмодерна
• "Ричард III и семиотика"
• 3D-визуализация обложки Ridero создаем обложку книги при работе над самиздатом.
• Архитектура метамодерна - говоря о современном искусстве, невозможно не поговорить об архитектуре. В данной статье будет отмечено несколько интересных принципов, характерных для построек "новой волны", столь притягательных и скандальных.
• Литература
• Метамодерн
• Рокер-Прометей против изначального зла в «Песне про советскую милицию» Вени Дркина, Автор: Нина Ищенко, к.ф.н, член Союза Писателей ЛНР - перепубликация из журнала "Топос".
• Как избавиться от комаров? Лучшие типы ловушек.
• Что делать если роблокс вылетает на windows
• Что делать, если ребенок смотрит порно?
• Почему собака прыгает на людей при встрече?
• Какое масло лить в Задний дифференциал (мост) Visco diff 38434AA050
• О чем может рассказать хвост вашей кошки?
• Верветки
• Отчетность бюджетных учреждений при закупках по Закону № 223-ФЗ
• Срок исковой давности как правильно рассчитать
• Дмитрий Патрушев минсельхоз будет ли преемником Путина
• Кто такой Владислав Поздняков? Что такое "Мужское Государство" и почему его признали экстремистским в России?
• Как правильно выбрать машинное масло в Димитровграде?
• Как стать богатым и знаменитым в России?
• Почему фильм "Пипец" (Kick-Ass) стал популярен по всему миру?
• Как стать мудрецом?
• Как правильно установить FreeBSD
• Как стать таким как Путин?
• Где лучше жить - в Димитровграде или в Ульяновске?
• Почему город Димитровград так называется?
• Что такое метамодерн?
• ВАЖНО! Временное ограничение движения автотранспортных средств в Димитровграде
• Тарифы на электроэнергию для майнеров предложено повысить

Различные производители придерживаются различных политик совместимости последовательных версий дистрибутивов и их обновлений с точки зрения сохранения работоспособности приложений (в первую очередь важно сохранение двоичной совместимости – для того, чтобы коммерче­ские приложения оставались рабочими без пересборки после обновления системы). Некоторые последовательные версии могут быть совместимыми, но в некоторых приходится нарушать совместимость ради возможности дальнейшего развития дистрибутива. Обновления в рамках одной мажорной версии у большинства дистрибутивов принято выпускать обратно совместимыми.

Для проверки совместимости исходного и обновленного дистрибутива есть несколько способов. В автоматиче­ском режиме совместимость всех системных библиотек может быть проверена с помощью специальных опций уже известного нам инструмента ABI Compliance Checker. Другой метод предполагает построение визуального отчета об изменениях в дистрибутиве с помощью инструмента DistDiff [7]. С помощью него мейнтейнер может быстро проанализировать все изменения в пакетах на совместимость.

[править] Заключение

Обновление пакетов – одна из основных и наиболее важных задач мейнтейнеров дистрибутивов Linux. От скорости выполнения этой задачи зависит актуальность дистрибутива для сообщества пользователей, от каче­ства – стабильность и совместимость новых релизов и обновлений. Оба эти показателя можно сущест­венно улучшить, если использовать упомянутые в статье свободные инструменты автоматизации разработки. |