Здравствуйте. Надеюсь, Саша не будет против публикации этого анализа и здесь. ----- Forwarded message from Alexander Bokovoy ----- Date: Wed, 25 Feb 2004 21:34:52 +0200 From: Alexander Bokovoy 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 ------ Linux.Kiev http://www.linux.kiev.ua/