[devel] Fwd: Re: [LINUX] Re: Fedora

[devel] Fwd: Re: [LINUX] Re: Fedora

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 6075 bytes --]

	Здравствуйте.
Надеюсь, Саша не будет против публикации этого анализа и здесь.

----- Forwarded message from Alexander Bokovoy <ab@samba.org> -----

Date: Wed, 25 Feb 2004 21:34:52 +0200
From: Alexander Bokovoy <ab@samba.org>
To: linux-list@linux.kiev.ua
Subject: Re: [LINUX] Re: Fedora

On Wed, Feb 25, 2004 at 08:37:01PM +0200, Michael Shigorin wrote:
> On Wed, Feb 25, 2004 at 06:03:49PM +0200, Victor Forsyuk wrote:
> > > Ты, небось, в курсе событий, включая причины.
> > Причина событий? Желание обновить ALM2.2 до текущего
> > репозитария разработки.
> 
> Ойблииин....
> 
> Там есть минимум две специфичные грабли из тех, что наносятся на
> карту имени upgrade path.
Грабли есть везде. Надо сказать, что много граблей во дворе старых
дистрибутивов разложено благодаря apt-у. Точнее тому, что apt развивается
и модифицируется, обнаруживаются некоторые ошибки в алгоритме выбора
зависимостей -- некоторые из них присутствовали и в основном apt-е в
Дебиан, причем даже в такой фундаментальной функции, как сравнение версий.
Исправления в этой области пришлись на период после выхода М2.2 (лето
2003-го).

Улучшение аналитической части apt-а помогает также выявить проблемы в
зависимостях пакетов. На самом деле, это очень сложный вопрос, который
многие пользователи дистрибутивов GNU/Linux просто не замечают. К
сожалению, некоторые производители дистрибутивов тоже. У последних это
связано с тем, что реальной возможности отслеживать такие проблемы
невозможно вручную; для этого нужен специальный аппарат, включающий в себя
целый ряд средств -- систему автоматической сборки пакетов в изолированной
среде, механизм хранения метаинформации о зависимостях всех типов, утилиты
автоматического вывода зависимостей из компонент пакетов вне зависимости
(извините за каламбур) от природы этих компонент.

Однако и этого недостаточно. Необходимо наличие достаточной базы
зависимостей всех типов, поддерживаемых пакетной системы. Например, целый
ряд проблем не виден, пока в дистрибутиве отсутствует виртуализация
пакетов. Как результат, не все производители добираются до понимания сложности 
проблемы. Три года назад работавших над подобными проблемами было меньше, чем 
пальцев одной руки -- Debian, SuSE, Conectiva и ALT. Через год к ним присоединился
Mandrake. RedHat под напором пользователей и успеха apt-rpm начал
предпринимать активные действия только в прошлом году.

Вернемся к сборочным средам. У SuSE и RedHat есть свои закрытые реализации
автоматических сборочных сред, приблизительно с 96-го года. В Debian -- с
аналогичного времени, но открытая. Автоматическая сборочная среда в ALT
Linux Team появилась почти два года назад, но полномасштабное применение
началось после выхода M2.2 -- до этого только пакеты минской группы
собирались в изолированной среде. Зато теперь у нас есть две независимых
реализации разного уровня и масштаба применения.

Система, аналогичная имеющемуся в ALT Linux Team hasher, появилась в
Mandrake два года назад и сильно улучшила ситуацию с зависимостями в
выпускаемых дистрибутивах. Правда, опыт Debian показывает, что всех
проблем избежать не удается -- в основном из-за того, что автоматическое
разрешение зависимостей разных типов на произвольно большом репозитарии
является NP-полной задачей, частным -- но не упрощенным -- случаем которой
является обновление одной пакетной базы до другой. Можно смотреть на это
как на поиск сети дорог, оптимально связывающих два графа в мультиграфе.

Вообщем, как можно догадаться, задачи подобного рода тесно связаны с
теорией графов и теорией расписаний. К сожалению, подавляющее большинство
разработчиков не владеет математическим аппаратом обеих для принятия
правильных решений. Убедить же менеджемент коммерческой компании в том,
что разрешение этих -- фундаментальных -- проблем приведет к увеличению
прибыли и оптимизации расходов в долгосрочной перспективе является
непростой задачей. Сужу по своему опыту -- потребовалось около года, чтобы
убедить своих американских коллег, занимающихся разработкой
специализированных appliances на базе GNU/Linux в том, что подобные проблемы 
вообще необходимо рассматривать -- до этого подход "зачем об этом
заботиться, мы просто возьмем пакеты из RedHat и положим рядом свои"
превалировал. А у подавляющего большинства компаний в нашей отрасли
(Networking Storages) остается по-прежнему главенствующим, несмотря на то,
что они фактически уже давно не работают с чистым RedHat, а пересобирают
практически 100% пакетов, составляющих основу дистрибутива, плюс свои
специфические ресурсы.

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

Но я отвлекся. Автоматизация поиска зависимостей в собираемых пакетах
позволяет улучшить понимание ситуации в репозитарии как для разработчиков,
которые не всегда имеют возможность анализировать код своих приложений,
так и для автоматических средств поддержания непротиворечивости состояния
репозитария. Простой пример -- какие пакеты необходимо пересобирать в
связи со сменой SONAME в какой-нибудь разделяемой библиотеке. Даже решение
такой, казалось бы простой, задачи позволяет увеличить прогнозируемость
работы R&D подразделения компании для управляющего персонала. Я не говорю
уже о свободных проектах, где это просто насущная необходимость в
противостоянии нарастанию энтропии в развитии проекта.

К сожалению, для пользователей весь этот процесс выглядит как "в пути
кормить не обещали", с соответствующей обратной реакцией.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

----- End forwarded message -----

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]