On 11/7/07, <b class="gmail_sendername">Alexey Tourbin</b> <<a href="mailto:at@altlinux.ru">at@altlinux.ru</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Nov 06, 2007 at 05:46:44PM +0300, Dmitry V. Levin wrote:<br>> Проблема в том, что действующую систему сборки хочется трогать как можно<br>> меньше, поскольку ещё есть надежда перейти на новую систему сборки<br>
> в обозримом будущем.<br><br>Надеяться не вредно. В свое время на консультации перед первым<br>экзаменом по высшей математике я задал преподавателю два вопроса:<br>1) какие оценки Вы обычно ставите; и 2) стоит ли надеяться на хорошую
<br>оценку. Ответы были соответственно 1) оценки бывают разные; и<br>2) надеяться можно всегда. (Оценка на экзамене была удовлетворительной --<br>я не понимал, что такое последовательность Коши. Через две недели я<br>пошел на пересдачу и мне поставили хорошую оценку. Полтора года спустя
<br>итоговая оценка была отличной.)<br><br>Можно не только надеяться, но и пытаться понять суть вещей.<br><br>Я предлагаю попытаться понять и обсуждать более фундаментальные вещи<br>(если есть что обсуждать), не опускаясь до техники реализации. Но это
<br>идёт рука об руку. Когда уже становится достаточно понятно, что нечно<br>подлежит реализации, то это становится достаточно просто реализовать.<br><br>Некоторое время назад я писал про желаемую процедуру прохождения<br>
пакетов. Теперь надо посмотреть на это с другой стороны -- на какой<br>структуре данных эта процедура будет работать.<br><br>Нужно дать "более алгебраическое" описание желаемой действительности,<br>а именно, какие элементарные множества у нас имеются, и какие
<br>элементарные операции к элементам этих множеств применимы.<br>Алгебраическая строгость, конечно, быстро пропадёт, но она по крайней<br>мере помогает понять "что к чему" на ранних этапах.<br><br>Я уже писал, что прохождение новых пакетов в сизиф подобно "коммитам"
<br>в некоем "репозитарии" пакетов (метарепозитарии). Наивная сериализация<br>склоняет к линейной истории коммитов, но практика говорит о том, что<br>любой "неудачный коммит" всего лишь открывает транзакцию, которая,
<br>при условии устранения всех "неудачных моментов" может быть потом<br>"слита" (merge) в mainline (HEAD) репозитария.<br><br>То есть, выражаясь более эзотерически, существует некий "холизм",
<br>когда "борьба" или "духовная брань" на земле отображется в это самое<br>дело на небе, а "поле битвы -- сердца людей" (Достоевский). Это значит,<br>что история "настоящего пакета" должна находить отражение в истории
<br>"метарепозитария" в целом. Прошу прощения за отклонение в изотерику.<br>Идея в целом достаточно важна, но мои вербальные возможности столь же<br>скудны.<br><br>Нет никакой нужды дальше поддерживать мнимое существование
<br>"метарепозитария Сизифа". Можно это понятие эксплицировать, и сказать,<br>что метарепозитария Сизифа -- это обычный git-репозитарий, в котором<br>хранится существенная информация о пакетах в Сизифе. Это информация
<br>является достаточной, а в основном и необходимой, для дальнейшего<br>продвижения "хеда" репозитария.<br><br>Короче, идея в следущем. Есть git-репозитарий сизифа. В нём существуют<br>подкаталоги по имени каждого
src.rpm пакета. Прохождение любого<br>пакета автоматически "влияет" на всё остальные (зависимые) пакеты по<br>крайней мере в смысле возможности пересборки.<br><br>Рассмотрим пример. Пришёл пакет perl-XML-LibXML, и он "собрался"
<br>(собираемость пакета является уточняемым понятием). Дальше предстоит<br>некое довольно долгое тестирование репозитария на предмет того, что<br>новый пакет ничего не ломает. Это значит, что каждый входящий пакет<br>открывает входящую транзакцию, по номеру серийного задания. Пусть номер
<br>задания будет 333, и пакет perl-XML-LibXML собрался. Создается бранч 333.<br><br> * branch 333: perl-XML-LibXML built ok<br> `* HEAD -- current sisyphus<br><br>Имеется попытка перевода репозитария в новое целостное состояние --
<br>с новым пакетом perl-XML-LibXML. Происходят всевозможные тестирования,<br>в частности, пересборка пакета perl-XML-LibXSLT.<br><br> * perl-XML-LibXSLT rebuilt ok (perl-XML-LibXSLT/ updated)<br> * branch 333: perl-XML-LibXML built ok
<br> `* HEAD -- current sisyphus<br><br>Когда всё тестирование прошло без обломов, тогда merge нового бранча<br>(или же "commit") происходит автоматически.<br><br> /* HEAD -- merge new perl-XML-LibXSLT into current sisyphus
<br> * | perl-XML-LibXSLT rebuilt ok (perl-XML-LibXSLT/ updated)<br> * | branch 333: perl-XML-LibXML built ok<br> `* HEAD -- current sisyphus<br><br>На самом деле здесь будет "fast forward", то есть в простейшем случае,
<br>если иметь в виду сериализацию заданий, не нарушается линейность истории.<br><br>В более неудачном случае merge не может быть простым "fast forward",<br>и здесь потребуется sophisticated стратегия мёржа. Стратегии мёржа
<br>метарепозитария я не буду обсуждать раньше времени, чтобы не усложнять<br>того что по сути просто.<br><br>Короче, есть такое дело -- МОЗГОВОЙ ШТУРМ.<br>Я предлагаю сделать метарепозитарий сизифа, в котором содержится<br>
необходимя и достаточная информация для поддержки "новой системы сборки<br>пакетов". На каждый src.rpm пакет имеется соответствующий подкаталог<br>метарепозитария.<br><br>Вопрос по части мозгового штурма у меня к вам простой -- ЧТО ДОЛЖНО
<br>ЛЕЖАТЬ В ПОДКАТАЛОГАХ ЭТОГО РЕПОЗИТАРИЯ? (У меня есть тетрадка в<br>которой исчеркано несколько страниц на эту тему... но я прошу высказать<br>то что сходу приходит вам в голову.)</blockquote><div><br></div>Если отталкиваться от текущей схемы работы с gear, то уже возникает целое множествое вариантов. Все они, в общем, сводятся к тому, что в подкаталоге
src.rpm пакета находятся набор файлов сборки, spec файл и правила формирования содержимого этого src.rpm пакета из набора файлов сборки. Стоит ли вводить строгий регламент на подробности внутренного содержимого этих каталогов свыше этой схемы для меня остаётся под вопросом, поскольку я не вижу для этого особых причин. Если расматривать каждый подкаталог как чёрный ящик, из которого формируется
src.rpm пакет, то текущей схемы вполне достаточно. Иначе возникают противоречивые варианты. Если хранить не распакованные исходники и патчи, то теряется большая часть преимуществ распределённой системы контроля версий, получатется, что, кроме spec файлов, нет смысла хранить в репозитарии остальную часть пакета, поскольку изменения и последующий мёрджинг tar файлов выглядит достаточно мрачно, не говоря уже о патчах на патчи... С другой стороны вариант, если хранить распакованные исходники в виде нескольких бранчей с разными патчами, из которых формируется итоговый мастер бранч, тоже влечёт ряд неисправимых проблем. В первую очередь - этo отход от политики "чистых" исходников, что у меня уже повлекло за собой ряд проблем, самая большая из которых состоит в том, что git не умеет (хотя я может быть ошибаюсь, исправьте, если я не прав) хранить пустые подкаталоги, что влечёт за собой, на вроде бы собираемом пакете, невозможность его пересборки из gear в исходном варианте.
<br>В процессе ответа у меня, в свою очередь, возник ряд вопросов. Что имеется в виду под метарепозитарием - один большой репозитарий или набор репозитариев для каждого из пакетов? Если имелось в виду первое, то есть идея действительно формировать его по общей схеме, когда из репозитария пакета формируется
src.rpm, который потом импортируется в необходимом виде в метарепозитарий. Но тут возникает другой вопрос. А что тогда считать более первичным?<br>В свете вышесказанного, пока могу предложить только вариант, при котором содержимое каждого каталога регламентировано только в том плане, что из него по общим правилам формируется
src.rpm пакет, как единственная точка опоры, к которой приводимы подкаталоги в метарепозитарии.<br><br clear="all"></div><br>-- <br>Sin (Sinelnikov Evgeny)