From: Michael Shigorin <mike@osdn.org.ua>
To: devel@altlinux.ru
Subject: [devel] Fwd: Re: [LINUX] Re: Fedora
Date: Wed, 25 Feb 2004 21:52:52 +0200
Message-ID: <20040225195252.GS23095@osdn.org.ua> (raw)
[-- 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 --]
reply other threads:[~2004-02-25 19:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040225195252.GS23095@osdn.org.ua \
--to=mike@osdn.org.ua \
--cc=devel@altlinux.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git