[devel] unmets policy

[devel] unmets policy

[Igor Vlasenko]

Уважаемые господа, 
раз уже с карманами у нас не складывается,
предлагаю к обсуждению
http://www.altlinux.org/Unmets_Creation_Policy

Unmets Creation Policy.
-----------------------

== Вводная часть ==

Unmets (unmet dependencies) -- зависимости пакета, которые 
не могут быть разрешены в существующем репозитарии.

В Сизифе не рекомендуется создавать unmet dependencies.
Рекомендуется переводить транзакциями репозитарий 
с одного устойчивого состояния в другое.

К сожалению, пока (до появления надлежащей реализации карманов?) 
некоторые транзакции и workflows сборочницей не поддерживаются.
В частности, не поддерживаются транзакции, включающие в себя несколько версий
одного и того же пакета (bootstrap-сборка).

Получается противоречие: сборочница не позволяет создать unmets,
в то время как для того, чтобы обновить пакет, unmets необходимо создать.

Это противоречие можно обойти, спрятав unmets под ковер: 
создав пакет-заглушку, который обманывает сборочную систему, 
фиктивно предоставляя отсутствующие Provides:.

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

== Требования к пакетам, прячущим unmets ==

Реальные пакеты не должны иметь фиктивных (закрывающих unmets) Provides.
Фиктивные Provides необходимо выделять в отдельный исходный пакет.

Название пакета должно иметь вид unment-dependency-<пакет, породивший unments>.

Обоснование: легкая фильтрация таких пакетов.

Рекомендуется делать пакет с фиктивными Provides: не устанавливаемым.
Для этого рекомендуется создавать файловый конфликт на существующий пакет.

AutoReqProv: noauto
Requires(pre): diffutils.
...
touch $RPM_BUILD_ROOT/usr/bin/diff
...

%files
/usr/bin/diff

Обоснование: чтобы пока в процессе обновления  Сизиф разломан,
пользователи не могли обновиться до разломанного состояния.

Рекомендуется ставить в пакете AutoReqProv: noauto,
все фиктивные Provides: прописывать вручную.

Обоснование: во избежание. Например, в примере выше можно на
автомате получить Provides: /usr/bin/diff.

== Требования к сборочной системе ==

желательно иметь возможность принудительное удалять пакеты,
несмотря на возникающие unmets.

В крайнем случае, при удалении пакета вида unment-dependency-*
проверка на возникающие unmets не должна проводиться.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] unmets policy

[Dmitry V. Levin]

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

On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote:
> Уважаемые господа, 
> раз уже с карманами у нас не складывается,
> предлагаю к обсуждению
> http://www.altlinux.org/Unmets_Creation_Policy
> 
> Unmets Creation Policy.
> -----------------------
> 
> == Вводная часть ==
> 
> Unmets (unmet dependencies) -- зависимости пакета, которые 
> не могут быть разрешены в существующем репозитарии.
> 
> В Сизифе не рекомендуется создавать unmet dependencies.
> Рекомендуется переводить транзакциями репозитарий 
> с одного устойчивого состояния в другое.
> 
> К сожалению, пока (до появления надлежащей реализации карманов?) 
> некоторые транзакции и workflows сборочницей не поддерживаются.
> В частности, не поддерживаются транзакции, включающие в себя несколько версий
> одного и того же пакета (bootstrap-сборка).

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


-- 
ldv

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

Re: [devel] unmets policy

[Igor Vlasenko]

On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote:
> > В частности, не поддерживаются транзакции, включающие в себя несколько версий
> > одного и того же пакета (bootstrap-сборка).
> 
> Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать
> анметы.

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] unmets policy

[Dmitry V. Levin]

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

On Tue, Sep 15, 2009 at 07:51:33PM +0300, Igor Vlasenko wrote:
> On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote:
> > > В частности, не поддерживаются транзакции, включающие в себя несколько версий
> > > одного и того же пакета (bootstrap-сборка).
> > 
> > Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать
> > анметы.
> 
> Поддерживаю. Но я не могу собирать пакеты с помощью того, чего нет.

Давайте сделаем то, что нужно, это же free software.


-- 
ldv

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

Re: [devel] unmets policy

[Alexey Tourbin]

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

On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote:
> On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote:
> > К сожалению, пока (до появления надлежащей реализации карманов?) 
> > некоторые транзакции и workflows сборочницей не поддерживаются.
> > В частности, не поддерживаются транзакции, включающие в себя несколько версий
> > одного и того же пакета (bootstrap-сборка).
> 
> Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать
> анметы.

Я не знаю как поддержать такие транзакции.  Точнее знаю.
Пусть пакеты в задании пронумерованы 1..n.  Предикат
пересечения x(i,j), i=1..n, j=1..n, i<j, означает что
в пределах задания пакет с большим номером j пересекается
с пакетом с меньшим номером i (по имени исходного пакета и/или
по имени одного из бинарных пакетов).  Тогда по смыслу пакет i
нужно выбросить из плана задания, потому что он был нужен
для бутстрапа пакета j.  Пакет j в свою очередь может быть
вытеснен пакетом с ещё большим номером.

Пересечение проверяется для всех пар (i,j).  Доказать что
окончательный план транзакции не зависит от порядка, в котором
проверяются пары (i,j).

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

В какой-то степени это конечно возражение против бутстрапа вообще.

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

Re: [devel] unmets policy

[Денис Смирнов]

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

On Tue, Sep 15, 2009 at 11:17:28PM +0400, Алексей Турбин wrote:

Темы pocket'ов и bootstrap'а связаны, но это не одно и то же.

pocket'ы могут быть "честными" (перенос из которых в Сизиф выполняется
обычными task'ами), а могут быть "не совсем честными".

Перенос из pocket'а в Сизиф методом копирования действительно порождает
множество потенциальных подводных граблей, вроде тех, о которых говорит
at@.

Однако если мы говорим о том, что перенос из pocket'ов в Сизиф может быть
исключительно обычными task'ами, то тогда практически все проблемы
расстворяются в воздухе :)

При этом остается одна нерешенная проблема -- bootstrap как таковой
необходим, это очевидно. Можно ради bootstrap'а держать в репозитории те
самые пакеты, с помощью которых реализовывался bootstrasp, пожизненно, но
это не имеет никакого смысла.

Таким образом все сводится к необходимости в task'ах, которые бы внутри
себя могли содержать:
- повторные пересборки одного и того же пакета
- добавление с последующим удалением пакета

Такими task'ами можно полностью обеспечить корректную интеграцию пакетов
из pocket'а в Сизиф.

При этом security проблемы оказываются несущественными -- у нас
сохраняется история всех task'ов, соответственно в случае атак на
репозиторий через bootstrap все будет задокументированно. Ситуация не
будет отличаться от существующей сейчас.

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

Возможно ли расширить текущую систему task'ов таким образом?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------


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

Re: [devel] unmets policy

[Alexey I. Froloff]

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

On Tue, Sep 15, 2009 at 11:17:28PM +0400, Alexey Tourbin wrote:
[..skip..]
> В какой-то степени это конечно возражение против бутстрапа вообще.
Можно делать бутстрап двумя разными транзакциями, первый раз
пакуя в пакет бинарные блобы (mingw, gnat).  Но это будет боль и
страдания для мантейнера.  Так ли нужна эта мифическая
транзакционность (A0->A1), которой всё равно никто не пользуется?

-- 
Regards,
Sir Raorn.

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

Re: [devel] unmets policy

[Dmitry V. Levin]

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

On Tue, Sep 15, 2009 at 11:17:28PM +0400, Alexey Tourbin wrote:
> On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote:
> > On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote:
> > > К сожалению, пока (до появления надлежащей реализации карманов?) 
> > > некоторые транзакции и workflows сборочницей не поддерживаются.
> > > В частности, не поддерживаются транзакции, включающие в себя несколько версий
> > > одного и того же пакета (bootstrap-сборка).
> > 
> > Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать
> > анметы.
> 
> Я не знаю как поддержать такие транзакции.  Точнее знаю.
> Пусть пакеты в задании пронумерованы 1..n.  Предикат
> пересечения x(i,j), i=1..n, j=1..n, i<j, означает что
> в пределах задания пакет с большим номером j пересекается
> с пакетом с меньшим номером i (по имени исходного пакета и/или
> по имени одного из бинарных пакетов).  Тогда по смыслу пакет i
> нужно выбросить из плана задания, потому что он был нужен
> для бутстрапа пакета j.  Пакет j в свою очередь может быть
> вытеснен пакетом с ещё большим номером.
> 
> Пересечение проверяется для всех пар (i,j).  Доказать что
> окончательный план транзакции не зависит от порядка, в котором
> проверяются пары (i,j).

Лучше сразу после сборки подзадания j выкинуть результат сборки всех
подзаданий i<j, которые пересекаются с результатом сборки подзадания j.
Я думаю, что мейнтейнеру будет проще предсказать поведение сборочной
системы, если она будет следовать этому правилу.

> В общем мне это не нравится, я бо так не стал делать.  Сейчас все
> транзакции прозрачны: результат сборки каждого пакета зависит от пакетов
> в репозитарии и дополнительно от пакетов с меньшими номерами, которые
> однако жо гарантированно попадают в репозиторий.  Прозрачность как бы
> означает, что имея начальный репозитарий A0 и конечный репозитарий A1,
> мы имеем все данные, чтобы заново проиграть транзакцию на репозитории
> A0 и получить в результате идентичный репозитарий A1.  А с бутстрапом
> такой прозрачности нет: имея на руках A0 и A1, мы не знаем, как
> на основе A0 воспроизвести A1 повтрно.

Нет, сейчас знания о A0 и A1 недостаточно для того, чтобы на основе A0
воспроизвести A1 повторно.  Для этого нужна дополнительная информация,
которая находится в задании A0->A1.


-- 
ldv

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

Re: [devel] unmets policy

[Alexey Tourbin]

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

On Tue, Sep 15, 2009 at 11:52:41PM +0400, Dmitry V. Levin wrote:
> On Tue, Sep 15, 2009 at 11:17:28PM +0400, Alexey Tourbin wrote:
> > On Tue, Sep 15, 2009 at 08:29:31PM +0400, Dmitry V. Levin wrote:
> > > On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote:
> > > > К сожалению, пока (до появления надлежащей реализации карманов?) 
> > > > некоторые транзакции и workflows сборочницей не поддерживаются.
> > > > В частности, не поддерживаются транзакции, включающие в себя несколько версий
> > > > одного и того же пакета (bootstrap-сборка).
> > > 
> > > Давайте лучше поддержим такие транзакции вместо того, чтобы узаконивать
> > > анметы.
> > 
> > Я не знаю как поддержать такие транзакции.  Точнее знаю.
> > Пусть пакеты в задании пронумерованы 1..n.  Предикат
> > пересечения x(i,j), i=1..n, j=1..n, i<j, означает что
> > в пределах задания пакет с большим номером j пересекается
> > с пакетом с меньшим номером i (по имени исходного пакета и/или
> > по имени одного из бинарных пакетов).  Тогда по смыслу пакет i
> > нужно выбросить из плана задания, потому что он был нужен
> > для бутстрапа пакета j.  Пакет j в свою очередь может быть
> > вытеснен пакетом с ещё большим номером.
> > 
> > Пересечение проверяется для всех пар (i,j).  Доказать что
> > окончательный план транзакции не зависит от порядка, в котором
> > проверяются пары (i,j).
> 
> Лучше сразу после сборки подзадания j выкинуть результат сборки всех
> подзаданий i<j, которые пересекаются с результатом сборки подзадания j.
> Я думаю, что мейнтейнеру будет проще предсказать поведение сборочной
> системы, если она будет следовать этому правилу.

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

Поэтому сейчас сборка идёт на repo + RPMS.hasher overlay, а план A0->A1
вычисляется только в самом конце.  Я когда-то решил что ничего лучше
придумать нельзя.  С наскоку по крайней мере.

А как сюда вписать дупы в пределах самого задания?  Сейчас работает
логика "в промежуточное состояние мы в принципе не вклиниваемся",
а дупы просто запрещены.  Поменять её на логику "в промежуточное
состояние мы в принципе вклиниваемся" это очень круто.

> > В общем мне это не нравится, я бо так не стал делать.  Сейчас все
> > транзакции прозрачны: результат сборки каждого пакета зависит от пакетов
> > в репозитарии и дополнительно от пакетов с меньшими номерами, которые
> > однако жо гарантированно попадают в репозиторий.  Прозрачность как бы
> > означает, что имея начальный репозитарий A0 и конечный репозитарий A1,
> > мы имеем все данные, чтобы заново проиграть транзакцию на репозитории
> > A0 и получить в результате идентичный репозитарий A1.  А с бутстрапом
> > такой прозрачности нет: имея на руках A0 и A1, мы не знаем, как
> > на основе A0 воспроизвести A1 повтрно.
> 
> Нет, сейчас знания о A0 и A1 недостаточно для того, чтобы на основе A0
> воспроизвести A1 повторно.  Для этого нужна дополнительная информация,
> которая находится в задании A0->A1.

Почему же недостаточно?  Достаточно, с точностью до некоторых
второстепенных атрибутов типа %packager.  То есть мы смотрим какие
новые пакеты есть в A1 и просто начинаем их собирать.  По окончанию
сборки удаляем старые пакеты и получается репозиторий идентичный A1.
Порядок сборки играет роль, но его можно узнать из buildtime/mtime.
Если бы даже порядок сборки был неизвествен, то его можно обнаружить
перебором.  То есть в принципе, плюс-минус тонкости, мы можем начать
собирать на A0 и получить A1.

А новую модель с бутстрапом в общем виде можно описать так.
Собрать n пакетов, выбрать из них m пакетов, m<n, и план составлять
только с учетом выбранных m пакетов.  Тогда ясно что если переход A0->A1
выполнен только с учетом m пакетов, то часть информации потерялась.
То есть начать собирать эти пакеты заново и получить A1 уже нельзя
даже в принципе.

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

Re: [devel] unmets policy

[Денис Смирнов]

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

On Wed, Sep 16, 2009 at 12:35:16AM +0400, Алексей Турбин wrote:

AT> Поэтому сейчас сборка идёт на repo + RPMS.hasher overlay, а план A0->A1
AT> вычисляется только в самом конце.  Я когда-то решил что ничего лучше
AT> придумать нельзя.  С наскоку по крайней мере.
AT> А как сюда вписать дупы в пределах самого задания?  Сейчас работает
AT> логика "в промежуточное состояние мы в принципе не вклиниваемся",
AT> а дупы просто запрещены.  Поменять её на логику "в промежуточное
AT> состояние мы в принципе вклиниваемся" это очень круто.

После сборки каждого пакета удалять дупы в оверлее?

Алгоритм следующий:
а) удалить все дупы по srpm;
б) удалить все бинарные пакеты, для которых были убиты srpm;
в) если после этого остались дупы по бинарным пакетам -- удалить
соответствующие srpm и повторить цикл

AT> А новую модель с бутстрапом в общем виде можно описать так.
AT> Собрать n пакетов, выбрать из них m пакетов, m<n, и план составлять
AT> только с учетом выбранных m пакетов.  Тогда ясно что если переход A0->A1
AT> выполнен только с учетом m пакетов, то часть информации потерялась.
AT> То есть начать собирать эти пакеты заново и получить A1 уже нельзя
AT> даже в принципе.

Да, сохранение информации из task'ов является необходимым, и от этого
никуда не убежать.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

[devel] bootstrap (was Re: unmets policy)

[Ivan A. Melnikov]

В Wed, 16 Sep 2009 00:35:16 +0400
Alexey Tourbin <at@altlinux.ru> пишет:
[...]
> 
> А новую модель с бутстрапом в общем виде можно описать так.
> Собрать n пакетов, выбрать из них m пакетов, m<n, и план составлять
> только с учетом выбранных m пакетов.  Тогда ясно что если переход
> A0->A1 выполнен только с учетом m пакетов, то часть информации
> потерялась. То есть начать собирать эти пакеты заново и получить A1
> уже нельзя даже в принципе.

Мне кажется, что суть бутстрапа в том, чтобы провести репозитарий через
промежуточное состояние, которое не публикуется. То есть, вместо
привычного A0->A1 мы хотим A0->A1->A2 в рамках одной танзакции, так,
чтобы для пользователя это выглядело как A0->A2, так как A1
промежуточное. Я недостаточно знаком с архитектурой git.alt, чтобы
сказать, к чему это ведёт -- к объединению нескольких task'ов в одной
транзкации (отсюда карманы, но тогда требуется снизить требования к
результатам промежуточных тасков) или появлению нескольких планов в
одном task'е.  Однако, в любом случае, информация о промежуточном
состоянии должна сохраняться.

-- 
WBR,
Ivan A. Melnikov

Re: [devel] unmets policy

[Vladislav Zavjalov]

> Я не знаю как поддержать такие транзакции.  Точнее знаю.
> Пусть пакеты в задании пронумерованы 1..n.  Предикат
> пересечения x(i,j), i=1..n, j=1..n, i<j, означает что
> в пределах задания пакет с большим номером j пересекается
> с пакетом с меньшим номером i (по имени исходного пакета и/или
> по имени одного из бинарных пакетов).  Тогда по смыслу пакет i
> нужно выбросить из плана задания, потому что он был нужен
> для бутстрапа пакета j.  Пакет j в свою очередь может быть
> вытеснен пакетом с ещё большим номером.
> 
> Пересечение проверяется для всех пар (i,j).  Доказать что
> окончательный план транзакции не зависит от порядка, в котором
> проверяются пары (i,j).
> 
> В общем мне это не нравится, я бо так не стал делать.  Сейчас все
> транзакции прозрачны: результат сборки каждого пакета зависит от пакетов
> в репозитарии и дополнительно от пакетов с меньшими номерами, которые
> однако жо гарантированно попадают в репозиторий.  Прозрачность как бы
> означает, что имея начальный репозитарий A0 и конечный репозитарий A1,
> мы имеем все данные, чтобы заново проиграть транзакцию на репозитории
> A0 и получить в результате идентичный репозитарий A1.  А с бутстрапом
> такой прозрачности нет: имея на руках A0 и A1, мы не знаем, как
> на основе A0 воспроизвести A1 повтрно.

Я правильно понимаю, что сейчас пакет из А1 может быть собран с некоторым
пакетом из А0 или из А1 - в зависимости от порядка пакетов в задании?
И только по А1 и А2 этого не поймешь.

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

Если смущает то, что при бутстрапе пакет может быть собран с пакетом из
А0, из А1 и с какой-то третьей версией, то, может, подойдет такая схема?

- идем по заданию, собираем пакет n в окружении А0 + пакеты 0..n-1
- если n вышибает какой-то предыдущий пакет m, то возвращаемся к
  пакету m+1 не обнуляя наше окружение и собираем дальше подряд.

так пакет m не окажется в сборочном окружении ни у кого.

Слава

Re: [devel] unmets policy

[Alexey Tourbin]

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

On Wed, Sep 16, 2009 at 07:03:15AM +0400, Денис Смирнов wrote:
> AT> Поэтому сейчас сборка идёт на repo + RPMS.hasher overlay, а план A0->A1
> AT> вычисляется только в самом конце.  Я когда-то решил что ничего лучше
> AT> придумать нельзя.  С наскоку по крайней мере.
> AT> А как сюда вписать дупы в пределах самого задания?  Сейчас работает
> AT> логика "в промежуточное состояние мы в принципе не вклиниваемся",
> AT> а дупы просто запрещены.  Поменять её на логику "в промежуточное
> AT> состояние мы в принципе вклиниваемся" это очень круто.
> 
> После сборки каждого пакета удалять дупы в оверлее?

Я же говорю, в промежуточное состояние мы в принципе не вклиниваемся.
То есть по принципиальным соображениям, это философия такая.  Если мы
вклиниваемся в промежуточное состояние, то автоматически встает вопрос,
какие требования мы предъявляем к промежуточному состоянию.  Например,
какие требования должны выполняться при замещениии пакетов.  Эти
требования появляются помимо нашего желания, сразу же как только мы
подумали что можно было бы немного вклиниться в промежуточное состояние.

> Алгоритм следующий:
> а) удалить все дупы по srpm;
> б) удалить все бинарные пакеты, для которых были убиты srpm;
> в) если после этого остались дупы по бинарным пакетам -- удалить
> соответствующие srpm и повторить цикл

Если удалять таким образом дупы в оверлее (после сборки каждого пакета),
то нужно таким же образом удалять дупы в основном репозитарии (после
сборки каждого пакета).  Это можно выразить так: hsh каждый раз должен
выполняться на репозитарии строго без дупов.

Теперь представь себе что был один исходный пакет и апстрим его попилил
на два исходных пакета.  Пусть например был исходный пакет xorg из
которого собиралась кучка пакетов типа libX11 а теперь ты залил пакет
libX11 который собирается сам из себя.  Теперь по пункту "б" надо делать
строгое замещение: выкинуть все иксы, а добавить только libX11.  Если мы
так сделаем (между сборкой первого и второго пакета), то с промежуточным
репозитарием произойдёт что-то очень нехорошее: в промежуточном
репозитарии появится слишком много анметов.  Но про это лучше не думать!

> AT> А новую модель с бутстрапом в общем виде можно описать так.
> AT> Собрать n пакетов, выбрать из них m пакетов, m<n, и план составлять
> AT> только с учетом выбранных m пакетов.  Тогда ясно что если переход A0->A1
> AT> выполнен только с учетом m пакетов, то часть информации потерялась.
> AT> То есть начать собирать эти пакеты заново и получить A1 уже нельзя
> AT> даже в принципе.
> 
> Да, сохранение информации из task'ов является необходимым, и от этого
> никуда не убежать.

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

Re: [devel] unmets policy

[Alexey Tourbin]

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

On Wed, Sep 16, 2009 at 12:28:51PM +0400, Vladislav Zavjalov wrote:
> > В общем мне это не нравится, я бо так не стал делать.  Сейчас все
> > транзакции прозрачны: результат сборки каждого пакета зависит от пакетов
> > в репозитарии и дополнительно от пакетов с меньшими номерами, которые
> > однако жо гарантированно попадают в репозиторий.  Прозрачность как бы
> > означает, что имея начальный репозитарий A0 и конечный репозитарий A1,
> > мы имеем все данные, чтобы заново проиграть транзакцию на репозитории
> > A0 и получить в результате идентичный репозитарий A1.  А с бутстрапом
> > такой прозрачности нет: имея на руках A0 и A1, мы не знаем, как
> > на основе A0 воспроизвести A1 повтрно.
> 
> Я правильно понимаю, что сейчас пакет из А1 может быть собран с некоторым
> пакетом из А0 или из А1 - в зависимости от порядка пакетов в задании?
> И только по А1 и А2 этого не поймешь.
> 
> В чем тогда заключается эта "прозрачность" и чем ее ухудшает бутстрап?
> Там тоже будет зависимость сборочной среды пакета от задания (правда,
> уже не только от порядка пакетов в задании)...

"Прозрачность" конечно плохое слово.  Лучше сказать, что задание
обладает абстрактным свойством CHLEN, если конечное состояние
репозитария (A1) содержит полную информацию о том, каким образом
оно было получено из начального состояния репозитария (A0) и
исходников.  Это значит что мы можем взять исходники из A1,
откатиться на A0, собрать исходники и снова получить A1.

А с бутстрапом есть промежуточные пакеты которые в репозитарий не
попадают.  Поэтому такие транзакции не обладают свойством CHLEN.

> Если смущает то, что при бутстрапе пакет может быть собран с пакетом из
> А0, из А1 и с какой-то третьей версией, то, может, подойдет такая схема?
> 
> - идем по заданию, собираем пакет n в окружении А0 + пакеты 0..n-1
> - если n вышибает какой-то предыдущий пакет m, то возвращаемся к
>   пакету m+1 не обнуляя наше окружение и собираем дальше подряд.
> 
> так пакет m не окажется в сборочном окружении ни у кого.

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

Re: [devel] bootstrap (was Re: unmets policy)

[Alexey Tourbin]

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

On Wed, Sep 16, 2009 at 11:16:59AM +0400, Ivan A. Melnikov wrote:
> > А новую модель с бутстрапом в общем виде можно описать так.
> > Собрать n пакетов, выбрать из них m пакетов, m<n, и план составлять
> > только с учетом выбранных m пакетов.  Тогда ясно что если переход
> > A0->A1 выполнен только с учетом m пакетов, то часть информации
> > потерялась. То есть начать собирать эти пакеты заново и получить A1
> > уже нельзя даже в принципе.
> 
> Мне кажется, что суть бутстрапа в том, чтобы провести репозитарий через
> промежуточное состояние, которое не публикуется. То есть, вместо
> привычного A0->A1 мы хотим A0->A1->A2 в рамках одной танзакции, так,
> чтобы для пользователя это выглядело как A0->A2, так как A1
> промежуточное.

Да.  Это довольно интересный и правильный взгляд.  Тогда опять же речь
идёт о том, какие требования должны предявлятся к A1.  То есть ясно что
можно ослабить требования на анметы, но например требования по
наследованию коммитов должны выполняться.

> Я недостаточно знаком с архитектурой git.alt, чтобы
> сказать, к чему это ведёт -- к объединению нескольких task'ов в одной
> транзкации (отсюда карманы, но тогда требуется снизить требования к
> результатам промежуточных тасков) или появлению нескольких планов в
> одном task'е.  Однако, в любом случае, информация о промежуточном
> состоянии должна сохраняться.

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

Re: [devel] unmets policy

[Vladislav Zavjalov]

 > "Прозрачность" конечно плохое слово.  Лучше сказать, что задание
 > обладает абстрактным свойством CHLEN, если конечное состояние
 > репозитария (A1) содержит полную информацию о том, каким образом
 > оно было получено из начального состояния репозитария (A0) и
 > исходников.  Это значит что мы можем взять исходники из A1,
 > откатиться на A0, собрать исходники и снова получить A1.

Разве сейчас это верно, если мы не знаем порядок сборки пакетов в
задании? Ведь пакеты из А1 могуть иметь в сборочном окружении другие
пакеты из А1.


Правильно ли я понимаю проблему:

мы имеем дело со следующими объектами:
- исходники -- git-репозитории
- задание -- список адресов в исходниках, которые надо собирать
- А0, А1 -- множества пар (результат сборки + адрес в исходниках)

Ты хочешь исключить из рассмотрения задание и после этого иметь
возможность повторить результат сборки любого пакета из А1?

Но как вообще можно пересобрать сборочно-зависимые друг от друга
пакеты, не имея информации, в каком порядке их собирать? А такой
информации нет ни в А0, ни в А1, ни в исходиках...

Слава

Re: [devel] unmets policy

[Денис Смирнов]

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

On Wed, Sep 16, 2009 at 02:32:38PM +0400, Алексей Турбин wrote:

AT> Я же говорю, в промежуточное состояние мы в принципе не вклиниваемся.
AT> То есть по принципиальным соображениям, это философия такая.  Если мы
AT> вклиниваемся в промежуточное состояние, то автоматически встает вопрос,
AT> какие требования мы предъявляем к промежуточному состоянию.  Например,
AT> какие требования должны выполняться при замещениии пакетов.  Эти
AT> требования появляются помимо нашего желания, сразу же как только мы
AT> подумали что можно было бы немного вклиниться в промежуточное состояние.

Разумеется.

>> Алгоритм следующий:
>> а) удалить все дупы по srpm;
>> б) удалить все бинарные пакеты, для которых были убиты srpm;
>> в) если после этого остались дупы по бинарным пакетам -- удалить
>> соответствующие srpm и повторить цикл
AT> Если удалять таким образом дупы в оверлее (после сборки каждого пакета),
AT> то нужно таким же образом удалять дупы в основном репозитарии (после
AT> сборки каждого пакета).  Это можно выразить так: hsh каждый раз должен
AT> выполняться на репозитарии строго без дупов.
AT> Теперь представь себе что был один исходный пакет и апстрим его попилил
AT> на два исходных пакета.  Пусть например был исходный пакет xorg из
AT> которого собиралась кучка пакетов типа libX11 а теперь ты залил пакет
AT> libX11 который собирается сам из себя.  Теперь по пункту "б" надо делать
AT> строгое замещение: выкинуть все иксы, а добавить только libX11.  Если мы
AT> так сделаем (между сборкой первого и второго пакета), то с промежуточным
AT> репозитарием произойдёт что-то очень нехорошее: в промежуточном
AT> репозитарии появится слишком много анметов.  Но про это лучше не думать!

Гм. Логично. То есть как только мы вводим понятие "удаление пакета внутри
таска, который мы собирали внутри этого же таска", или когда выполняется
замещение пакетов внутри таска -- в этот момент использование оверлея
порождает слишком много side effects и требуется отказаться от оверлея и
сформировать новый репозиторий.

Да, тогда моя идея не работает :(

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Wed, Sep 16, 2009 at 11:16:59AM +0400, Ivan A. Melnikov wrote:

IAM> Мне кажется, что суть бутстрапа в том, чтобы провести репозитарий через
IAM> промежуточное состояние, которое не публикуется. То есть, вместо
IAM> привычного A0->A1 мы хотим A0->A1->A2 в рамках одной танзакции, так,
IAM> чтобы для пользователя это выглядело как A0->A2, так как A1
IAM> промежуточное. Я недостаточно знаком с архитектурой git.alt, чтобы
IAM> сказать, к чему это ведёт -- к объединению нескольких task'ов в одной
IAM> транзкации (отсюда карманы, но тогда требуется снизить требования к
IAM> результатам промежуточных тасков) или появлению нескольких планов в
IAM> одном task'е.  Однако, в любом случае, информация о промежуточном
IAM> состоянии должна сохраняться.

Хорошая идея и простая :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Wed, Sep 16, 2009 at 03:03:23PM +0400, Алексей Турбин wrote:

AT> Да.  Это довольно интересный и правильный взгляд.  Тогда опять же речь
AT> идёт о том, какие требования должны предявлятся к A1.  То есть ясно что
AT> можно ослабить требования на анметы, но например требования по
AT> наследованию коммитов должны выполняться.

Насколько я понимаю проверка acl и наследования выполняется н этапе
добавления subtask'ов, а проверки на unmet'ы и устанавливаемость -- после
завершения task'а.

Мне кажется логичным ничего в этой системе не менять, но добавить внутри
task'а команду генерирования нового промежуточного репозитория. Т.е.
выглядить это может как:

task add repo package-stub ...
task add repo some-package ...
task add rebuild-repo
tash add repo some-package [тэг с новой версией]

в этом случае:
- мы не имеем overhead для задач, где bootstrap не нужен
- если bootstrap нужен -- есть возможность в любой момент "оторвать"
  overlay сгенерировав новой временный репозиторий, сборка внутри которого
  опять будет использовать оверлеи

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Vladislav Zavjalov]

> Мне кажется логичным ничего в этой системе не менять, но добавить внутри
> task'а команду генерирования нового промежуточного репозитория. Т.е.
> выглядить это может как:
> 
> task add repo package-stub ...
> task add repo some-package ...
> task add rebuild-repo
> tash add repo some-package [тэг с новой версией]

А кроме того, это позволит ввести операцию сложения заданий, разделяя
их этим самым rebuild-repo!

"Прозрачность" А.Т. кажется довольно бесполезной без хранения всех состояний.
(ведь даже переход A0->A2 уже не всегда "прозрачен").

Не лучше ли вместо этого работать именно с заданиями, переводящими
репозиторий из одного допустимого состояния в другое. Хранить их,
складывать, (разделяя этим самым rebuild-repo), пытаться применять к разным
состояниям...

Слава

Re: [devel] unmets policy

[Vladislav Zavjalov]

On Wed, Sep 16, 2009 at 04:32:57PM +0400, Vladislav Zavjalov wrote:
> > "Прозрачность" конечно плохое слово.  Лучше сказать, что задание
> > обладает абстрактным свойством CHLEN, если конечное состояние
> > репозитария (A1) содержит полную информацию о том, каким образом
> > оно было получено из начального состояния репозитария (A0) и
> > исходников.  Это значит что мы можем взять исходники из A1,
> > откатиться на A0, собрать исходники и снова получить A1.
> 
> Но как вообще можно пересобрать сборочно-зависимые друг от друга
> пакеты, не имея информации, в каком порядке их собирать? А такой
> информации нет ни в А0, ни в А1, ни в исходиках...

Да, про то, что в состоянии хранится еще и время сборки пакетов, 
я сам не смог догадаться :) Вопрос снимается...

Слава

Re: [devel] bootstrap (was Re: unmets policy)

[Dmitry V. Levin]

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

On Wed, Sep 16, 2009 at 09:38:25PM +0400, Денис Смирнов wrote:
> On Wed, Sep 16, 2009 at 03:03:23PM +0400, Алексей Турбин wrote:
> 
> AT> Да.  Это довольно интересный и правильный взгляд.  Тогда опять же речь
> AT> идёт о том, какие требования должны предявлятся к A1.  То есть ясно что
> AT> можно ослабить требования на анметы, но например требования по
> AT> наследованию коммитов должны выполняться.
> 
> Насколько я понимаю проверка acl и наследования выполняется н этапе
> добавления subtask'ов, а проверки на unmet'ы и устанавливаемость -- после
> завершения task'а.

Нет, проверка наследования сейчас производится уже после проверок на
анметы и установку, а проверка acl -- после проверки наследования.


-- 
ldv

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

Re: [devel] unmets policy

[Alexey Tourbin]

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

On Wed, Sep 16, 2009 at 09:32:06PM +0400, Денис Смирнов wrote:
> >> Алгоритм следующий:
> >> а) удалить все дупы по srpm;
> >> б) удалить все бинарные пакеты, для которых были убиты srpm;
> >> в) если после этого остались дупы по бинарным пакетам -- удалить
> >> соответствующие srpm и повторить цикл
> AT> Если удалять таким образом дупы в оверлее (после сборки каждого пакета),
> AT> то нужно таким же образом удалять дупы в основном репозитарии (после
> AT> сборки каждого пакета).  Это можно выразить так: hsh каждый раз должен
> AT> выполняться на репозитарии строго без дупов.
> AT> Теперь представь себе что был один исходный пакет и апстрим его попилил
> AT> на два исходных пакета.  Пусть например был исходный пакет xorg из
> AT> которого собиралась кучка пакетов типа libX11 а теперь ты залил пакет
> AT> libX11 который собирается сам из себя.  Теперь по пункту "б" надо делать
> AT> строгое замещение: выкинуть все иксы, а добавить только libX11.  Если мы
> AT> так сделаем (между сборкой первого и второго пакета), то с промежуточным
> AT> репозитарием произойдёт что-то очень нехорошее: в промежуточном
> AT> репозитарии появится слишком много анметов.  Но про это лучше не думать!
> 
> Гм. Логично. То есть как только мы вводим понятие "удаление пакета внутри
> таска, который мы собирали внутри этого же таска", или когда выполняется
> замещение пакетов внутри таска -- в этот момент использование оверлея
> порождает слишком много side effects и требуется отказаться от оверлея и
> сформировать новый репозиторий.

С одной стороны никто не может запретить нам плюхать что угодно куда
угодно.  (Но это как бы глупо.)

С другой стороны мы должны думать, что от чего зависит, и в какой
степени мы умеем это воспроизвести.  Или же там значит какие-то тайны
Божьи происходят, которые пробовать воспроизвести это грех.

Я считаю что говорить в терминах воспроизводства результата это неплохая
отправная точка для разговора о пакетах вообще.

> Да, тогда моя идея не работает :(

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Wed, Sep 16, 2009 at 09:59:23PM +0400, Vladislav Zavjalov wrote:

>> task add repo package-stub ...
>> task add repo some-package ...
>> task add rebuild-repo
>> tash add repo some-package [тэг с новой версией]
VZ> А кроме того, это позволит ввести операцию сложения заданий, разделяя
VZ> их этим самым rebuild-repo!

Да, именно так. Но для чего нужна такая операция?

VZ> "Прозрачность" А.Т. кажется довольно бесполезной без хранения всех состояний.
VZ> (ведь даже переход A0->A2 уже не всегда "прозрачен").

Эта прозрачность безусловно полезна, но информации содержащейся в A0, A1 и
A2 для этого недостаточно -- сохранение содержимого task'ов необходимо. А
раз оно и так необходимо, то предлагаемое изменение никак не повлияет на
эту самую прозрачность :)

VZ> Не лучше ли вместо этого работать именно с заданиями, переводящими
VZ> репозиторий из одного допустимого состояния в другое. Хранить их,
VZ> складывать, (разделяя этим самым rebuild-repo), пытаться применять к разным
VZ> состояниям...

Да.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Wed, Sep 16, 2009 at 11:09:41PM +0400, Dmitry V. Levin wrote:

DVL> Нет, проверка наследования сейчас производится уже после проверок на
DVL> анметы и установку, а проверка acl -- после проверки наследования.

Этому есть технические причины, или какие-либо другие?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Dmitry V. Levin]

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

On Thu, Sep 17, 2009 at 02:27:28AM +0400, Денис Смирнов wrote:
> On Wed, Sep 16, 2009 at 11:09:41PM +0400, Dmitry V. Levin wrote:
> 
> DVL> Нет, проверка наследования сейчас производится уже после проверок на
> DVL> анметы и установку, а проверка acl -- после проверки наследования.
> 
> Этому есть технические причины, или какие-либо другие?

Логические.  acl после успешной сборки можно подправить, историю перекроить,
а вот если пакет не устанавливается, то ничего с ним уже не сделаешь.


-- 
ldv

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

Re: [devel] bootstrap (was Re: unmets policy)

[Alexey Tourbin]

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

On Wed, Sep 16, 2009 at 09:59:23PM +0400, Vladislav Zavjalov wrote:
> > Мне кажется логичным ничего в этой системе не менять, но добавить внутри
> > task'а команду генерирования нового промежуточного репозитория. Т.е.
> > выглядить это может как:
> > 
> > task add repo package-stub ...
> > task add repo some-package ...
> > task add rebuild-repo
> > tash add repo some-package [тэг с новой версией]
> 
> А кроме того, это позволит ввести операцию сложения заданий, разделяя
> их этим самым rebuild-repo!
> 
> "Прозрачность" А.Т. кажется довольно бесполезной без хранения всех состояний.
> (ведь даже переход A0->A2 уже не всегда "прозрачен").

Вы зрите в корень!  Если есть две CHLEN-транзакции A0->A1 и A1->A2,
то комбинированный переход A0->A2, вообще говоря, уже не обладает
свойством CHLEN.  Потому что там могут быть промежуточные пакеты,
которые вошли и вышли, но оказали влияние; и воспроизвести это уже
никак нельзя.

То что CHLEN-свойство бесполезно это очень громко сказано.
Хотя я и не говорил, что оно чрезвычайно полезно.  Но при атомарных
переходах надо думать о сохранении информации в самом репозитарии.
Можем мы воспроизвести этот атомарный переход (в случае чего) или нет.

> Не лучше ли вместо этого работать именно с заданиями, переводящими
> репозиторий из одного допустимого состояния в другое. Хранить их,
> складывать, (разделяя этим самым rebuild-repo), пытаться применять к разным
> состояниям...

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

Re: [devel] bootstrap (was Re: unmets policy)

[Vladislav Zavjalov]

> То что CHLEN-свойство бесполезно это очень громко сказано.
> Хотя я и не говорил, что оно чрезвычайно полезно.  Но при атомарных
> переходах надо думать о сохранении информации в самом репозитарии.
> Можем мы воспроизвести этот атомарный переход (в случае чего) или нет.

А что мы хотим воспроизвести? По исходникам, А0 и А1 воспроизвести любой
пакет А1? Но если этого пакета нет в А1, то мы его не сможем
воспроизвести - не хватит данных. А если есть - то зачем воспроизводить?
Если же пакет как-то испортился, то мы можем (причем не всегда!) только
подтвердить этот факт, но не восстановить пакет.

Не лучше ли хранить информацию о заданиях - тогда-то мы точно
сможем все воспроизвести.

Это свойство Chlen-прозрачности напоминает требование какой-то хитрой
связности подмножества допустимых состояний, по которому мы ходим.

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

Слава

Re: [devel] bootstrap (was Re: unmets policy)

[Vladislav Zavjalov]

On Thu, Sep 17, 2009 at 02:27:00AM +0400, Денис Смирнов wrote:
> On Wed, Sep 16, 2009 at 09:59:23PM +0400, Vladislav Zavjalov wrote:
> 
> >> task add repo package-stub ...
> >> task add repo some-package ...
> >> task add rebuild-repo
> >> tash add repo some-package [тэг с новой версией]
> VZ> А кроме того, это позволит ввести операцию сложения заданий, разделяя
> VZ> их этим самым rebuild-repo!
> 
> Да, именно так. Но для чего нужна такая операция?

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

> VZ> "Прозрачность" А.Т. кажется довольно бесполезной без хранения всех состояний.
> VZ> (ведь даже переход A0->A2 уже не всегда "прозрачен").
> 
> Эта прозрачность безусловно полезна, но информации содержащейся в A0, A1 и
> A2 для этого недостаточно -- сохранение содержимого task'ов необходимо. А
> раз оно и так необходимо, то предлагаемое изменение никак не повлияет на
> эту самую прозрачность :)

Сравниваем А0 и А1. Получаем список <время сборки> <пакет> <версия>.
Упорядочиваем по времени, изыскиваем тэги в git.alt. Для "прозрачных"
заданий это и есть task.

Слава

Re: [devel] bootstrap (was Re: unmets policy)

[Kirill A. Shutemov]

2009/9/17 Vladislav Zavjalov <slazav@altlinux.org>:
> Сравниваем А0 и А1. Получаем список <время сборки> <пакет> <версия>.
> Упорядочиваем по времени, изыскиваем тэги в git.alt. Для "прозрачных"
> заданий это и есть task.

Так можно восстановить только задания без удаления пакетов или задания
в котором удаляется один пакет и сборки пакетов не происходит. Так
невозможно восстановить порядок удаления пакетов.

Re: [devel] bootstrap (was Re: unmets policy)

[Dmitry V. Levin]

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

On Thu, Sep 17, 2009 at 10:35:27AM +0300, Kirill A. Shutemov wrote:
> 2009/9/17 Vladislav Zavjalov <slazav@altlinux.org>:
> > Сравниваем А0 и А1. Получаем список <время сборки> <пакет> <версия>.
> > Упорядочиваем по времени, изыскиваем тэги в git.alt. Для "прозрачных"
> > заданий это и есть task.
> 
> Так можно восстановить только задания без удаления пакетов или задания
> в котором удаляется один пакет и сборки пакетов не происходит. Так
> невозможно восстановить порядок удаления пакетов.

Сейчас сборочница не реализует никакого порядка удаления пакетов, все
подзадания на удаление выполняются после сборки всех остальных подзаданий.
Это позволяет сэкономить на перегенерации временных сизифов.


-- 
ldv

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

Re: [devel] bootstrap (was Re: unmets policy)

[Kirill A. Shutemov]

2009/9/17 Dmitry V. Levin <ldv@altlinux.org>:
> On Thu, Sep 17, 2009 at 10:35:27AM +0300, Kirill A. Shutemov wrote:
>> 2009/9/17 Vladislav Zavjalov <slazav@altlinux.org>:
>> > Сравниваем А0 и А1. Получаем список <время сборки> <пакет> <версия>.
>> > Упорядочиваем по времени, изыскиваем тэги в git.alt. Для "прозрачных"
>> > заданий это и есть task.
>>
>> Так можно восстановить только задания без удаления пакетов или задания
>> в котором удаляется один пакет и сборки пакетов не происходит. Так
>> невозможно восстановить порядок удаления пакетов.
>
> Сейчас сборочница не реализует никакого порядка удаления пакетов, все
> подзадания на удаление выполняются после сборки всех остальных подзаданий.
> Это позволяет сэкономить на перегенерации временных сизифов.

А корректно ли это?

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Thu, Sep 17, 2009 at 11:09:11AM +0400, Vladislav Zavjalov wrote:

VZ> А непонятно. В твоем примере она нужна, чтоб сложить два "прозрачных"
VZ> задания в одно "непрозрачное" и тем самым перешагнуть через недопустимое
VZ> состояние. Но, очевидно, возможность такого сложения убивает всю идею
VZ> "прозрачности" :)

Она и так убита, уже давно.

Привожу интересный пример:

Есть пакеты, скажем mycc1, mycc2. Предположим это такой компилятор с моего
собственного языка программирования, который почти как C ну круче. Они оба
provides mycc.

Теперь я хочу собрать новую крутую версию пакета mycc2.1, который,
разумеется, собирается только компиляторами mycc. В BuildRequires у него
написано: mycc.

Вариант task'а #1:
ssh git.alt task add repo mycc2.1 ...
ssh git.alt task del mycc2

в этой ситуации, очевидно, mycc2.1 будет собран с помощью mycc2.

Вариант task'а #2:
ssh git.alt task del mycc2
ssh git.alt task add repo mycc2.1

в этой ситуации, очевидно, mycc2.1 _должен быть_ собран с помощью mycc1.
При этом как себя поведет сборочница в этой ситуации я не очень понимаю.

В обоих случаях мы получаем абсолютно идентичный результат в A1 по списку
пакетов. Однако реально мы получаем совершенно разные результаты! Например
потому, что mycc2 содержал ошибку в кодогенераторе (из-за которой мы и
затеяли это обновление) и поэтому собранные mycc2.1 в первом случае падать
вместо работы, а во втором -- работать.

Могу повторить еще раз свою мысль -- в настоящий момент наличие снапшотов
репозиториев A0 и A1 не позволяет получить полноценную информацию о том,
каким образом из A0 получили A1. Это технически невозможно без информации
а git.alt/gears и содержимого task'ов.

Кроме того, принципиаьлный вопрос -- а где-то сохраняются _все_ снапшоты
Сизифа после _каждого_ коммита транзакции? Сильно сомневаюсь, таким
образом этой информации в настоящий момент у нас просто нет, если мы не
будем смотреть в task'и.

А если мы смотрим в task'и, то всякие временные репозитории нас не пугают
:)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Thu, Sep 17, 2009 at 11:47:41AM +0300, Kirill A. Shutemov wrote:
>> Сейчас сборочница не реализует никакого порядка удаления пакетов, все
>> подзадания на удаление выполняются после сборки всех остальных подзаданий.
>> Это позволяет сэкономить на перегенерации временных сизифов.
KAS> А корректно ли это?

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

Если мы вводим команду перегенерирования Сизифа внутри task'а, тогда можно
в тех немногих случаях когда это действительно нужно -- выполнять удаление
отдеьлно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Thu, Sep 17, 2009 at 03:01:40AM +0400, Dmitry V. Levin wrote:

DVL> Логические.  acl после успешной сборки можно подправить, историю перекроить,
DVL> а вот если пакет не устанавливается, то ничего с ним уже не сделаешь.

То есть это сделано для того, чтобы можно было на сборочнице собрать
пакет, который заведомо не пройдет в Сизиф (по acl или наследованию),
чтобы можно было полностью проверить его корректность, а уж потом решать
вопросы с acl и т.д., я правильно понял?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Vladislav Zavjalov]

On Thu, Sep 17, 2009 at 10:12:52PM +0400, Денис Смирнов wrote:
> On Thu, Sep 17, 2009 at 11:09:11AM +0400, Vladislav Zavjalov wrote:
> 
> VZ> А непонятно. В твоем примере она нужна, чтоб сложить два "прозрачных"
> VZ> задания в одно "непрозрачное" и тем самым перешагнуть через недопустимое
> VZ> состояние. Но, очевидно, возможность такого сложения убивает всю идею
> VZ> "прозрачности" :)
> 
> Она и так убита, уже давно.
> 
> Привожу интересный пример:

А ldv тут в соседнем сообщении пишет:

>> Сейчас сборочница не реализует никакого порядка удаления пакетов, все
>> подзадания на удаление выполняются после сборки всех остальных
>> подзаданий.
>> Это позволяет сэкономить на перегенерации временных сизифов.

Так что прозрачность кажется пока живой.

> Кроме того, принципиаьлный вопрос -- а где-то сохраняются _все_ снапшоты
> Сизифа после _каждого_ коммита транзакции? Сильно сомневаюсь, таким
> образом этой информации в настоящий момент у нас просто нет, если мы не
> будем смотреть в task'и.
> 
> А если мы смотрим в task'и, то всякие временные репозитории нас не пугают
> :)

А про это я и говорил, что "Прозрачность" А.Т. кажется довольно
бесполезной без хранения всех состояний.

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

Слава

Re: [devel] bootstrap (was Re: unmets policy)

[Vladislav Zavjalov]

On Thu, Sep 17, 2009 at 10:25:33PM +0400, Vladislav Zavjalov wrote:
> On Thu, Sep 17, 2009 at 10:12:52PM +0400, Денис Смирнов wrote:
> > On Thu, Sep 17, 2009 at 11:09:11AM +0400, Vladislav Zavjalov wrote:
> > 
> > VZ> А непонятно. В твоем примере она нужна, чтоб сложить два "прозрачных"
> > VZ> задания в одно "непрозрачное" и тем самым перешагнуть через недопустимое
> > VZ> состояние. Но, очевидно, возможность такого сложения убивает всю идею
> > VZ> "прозрачности" :)
> > 
> > Она и так убита, уже давно.
> > 
> > Привожу интересный пример:
> 
> А ldv тут в соседнем сообщении пишет:
> 
> >> Сейчас сборочница не реализует никакого порядка удаления пакетов, все
> >> подзадания на удаление выполняются после сборки всех остальных
> >> подзаданий.
> >> Это позволяет сэкономить на перегенерации временных сизифов.
> 
> Так что прозрачность кажется пока живой.

Хотя, может и нет:
- собрали А
- собрали Б
- удалили А

Вот что при этом будет?

Слава

Re: [devel] bootstrap (was Re: unmets policy)

[Dmitry V. Levin]

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

On Thu, Sep 17, 2009 at 10:44:07PM +0400, Vladislav Zavjalov wrote:
> On Thu, Sep 17, 2009 at 10:25:33PM +0400, Vladislav Zavjalov wrote:
> > On Thu, Sep 17, 2009 at 10:12:52PM +0400, Денис Смирнов wrote:
> > > On Thu, Sep 17, 2009 at 11:09:11AM +0400, Vladislav Zavjalov wrote:
> > > 
> > > VZ> А непонятно. В твоем примере она нужна, чтоб сложить два "прозрачных"
> > > VZ> задания в одно "непрозрачное" и тем самым перешагнуть через недопустимое
> > > VZ> состояние. Но, очевидно, возможность такого сложения убивает всю идею
> > > VZ> "прозрачности" :)
> > > 
> > > Она и так убита, уже давно.
> > > 
> > > Привожу интересный пример:
> > 
> > А ldv тут в соседнем сообщении пишет:
> > 
> > >> Сейчас сборочница не реализует никакого порядка удаления пакетов, все
> > >> подзадания на удаление выполняются после сборки всех остальных
> > >> подзаданий.
> > >> Это позволяет сэкономить на перегенерации временных сизифов.
> > 
> > Так что прозрачность кажется пока живой.
> 
> Хотя, может и нет:
> - собрали А
> - собрали Б
> - удалили А
> 
> Вот что при этом будет?

Сейчас, если попробовать сделать это одной транзакцией, то будет
FAILED to delete just built packages


-- 
ldv

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

Re: [devel] bootstrap (was Re: unmets policy)

[Dmitry V. Levin]

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

On Thu, Sep 17, 2009 at 10:16:10PM +0400, Денис Смирнов wrote:
> On Thu, Sep 17, 2009 at 03:01:40AM +0400, Dmitry V. Levin wrote:
> 
> DVL> Логические.  acl после успешной сборки можно подправить, историю перекроить,
> DVL> а вот если пакет не устанавливается, то ничего с ним уже не сделаешь.
> 
> То есть это сделано для того, чтобы можно было на сборочнице собрать
> пакет, который заведомо не пройдет в Сизиф (по acl или наследованию),
> чтобы можно было полностью проверить его корректность, а уж потом решать
> вопросы с acl и т.д., я правильно понял?

Да.


-- 
ldv

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Thu, Sep 17, 2009 at 07:50:06AM +0400, Алексей Турбин wrote:

AT> Вы зрите в корень!  Если есть две CHLEN-транзакции A0->A1 и A1->A2,
AT> то комбинированный переход A0->A2, вообще говоря, уже не обладает
AT> свойством CHLEN.  Потому что там могут быть промежуточные пакеты,
AT> которые вошли и вышли, но оказали влияние; и воспроизвести это уже
AT> никак нельзя.

Можно -- у нас есть содержимое task'ов. А без содержимого task'ов и сейчас
нельзя, или действительно сохраняется полный снапшот Сизифа после каждой
транзакции?

AT> То что CHLEN-свойство бесполезно это очень громко сказано.
AT> Хотя я и не говорил, что оно чрезвычайно полезно.  Но при атомарных
AT> переходах надо думать о сохранении информации в самом репозитарии.
AT> Можем мы воспроизвести этот атомарный переход (в случае чего) или нет.

Я не понимаю зачем нам сохранять это в самом репозитории, как наборе
rpm-пакетов, когда у нас есть такие замечательные task'и. Особенно с
учетом того что в будущем от srpm планируется отказаться -- соответственн
репозиторий перестанет вообще содержать эту информацию без соответствующих
git-repo.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] bootstrap (was Re: unmets policy)

[Dmitry V. Levin]

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

On Fri, Sep 18, 2009 at 01:21:22AM +0400, Денис Смирнов wrote:
> On Thu, Sep 17, 2009 at 07:50:06AM +0400, Алексей Турбин wrote:
> 
> AT> Вы зрите в корень!  Если есть две CHLEN-транзакции A0->A1 и A1->A2,
> AT> то комбинированный переход A0->A2, вообще говоря, уже не обладает
> AT> свойством CHLEN.  Потому что там могут быть промежуточные пакеты,
> AT> которые вошли и вышли, но оказали влияние; и воспроизвести это уже
> AT> никак нельзя.
> 
> Можно -- у нас есть содержимое task'ов. А без содержимого task'ов и сейчас
> нельзя, или действительно сохраняется полный снапшот Сизифа после каждой
> транзакции?

Нет, не сохраняется, к сожалению.


-- 
ldv

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

Re: [devel] bootstrap (was Re: unmets policy)

[Денис Смирнов]

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

On Fri, Sep 18, 2009 at 01:37:22AM +0400, Dmitry V. Levin wrote:

>> Можно -- у нас есть содержимое task'ов. А без содержимого task'ов и сейчас
>> нельзя, или действительно сохраняется полный снапшот Сизифа после каждой
>> транзакции?
DVL> Нет, не сохраняется, к сожалению.

В таком случае получается, что ценность возможности воспроизвести
изменение A0->A2 по информации содержащейся исключительно внутри этих
репозиториев без содержимого task'а равна нулю?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

[devel] unmets policy - summary

[Igor Vlasenko]

Позволю себе подвести итоги обсуждения Unmets Creation Policy.

1) Все участники обсуждения были единодушны в том,
что хорошо было бы допилить сборочницу так, чтобы нужды в нем 
не было бы.

2) По поводу самого полиси возражений не было.

3) Сборочницу никто не допилил :)

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


On Tue, Sep 15, 2009 at 06:25:10PM +0300, Igor Vlasenko wrote:
> Уважаемые господа, 
> раз уже с карманами у нас не складывается,
> предлагаю к обсуждению
> http://www.altlinux.org/Unmets_Creation_Policy
-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] unmets policy - summary

[Michael Shigorin]

On Wed, Sep 23, 2009 at 07:17:07PM +0300, Igor Vlasenko wrote:
> Предлагаю принять как временное полиси

ack

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

Re: [devel] unmets policy - summary

[Igor Vlasenko]

On Mon, Sep 28, 2009 at 10:34:33PM +0300, Michael Shigorin wrote:
> On Wed, Sep 23, 2009 at 07:17:07PM +0300, Igor Vlasenko wrote:
> > Предлагаю принять как временное полиси
> ack
Возражений не было, процедуры пройдены -
значит полиси принято. Завтра напишу анонс.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] unmets policy - summary

[Alexey Tourbin]

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

On Tue, Sep 29, 2009 at 09:29:33PM +0300, Igor Vlasenko wrote:
> On Mon, Sep 28, 2009 at 10:34:33PM +0300, Michael Shigorin wrote:
> > On Wed, Sep 23, 2009 at 07:17:07PM +0300, Igor Vlasenko wrote:
> > > Предлагаю принять как временное полиси
> > ack
> Возражений не было, процедуры пройдены -
> значит полиси принято. Завтра напишу анонс.

Возражения есть.  Проверка на анметы -- эта проверка для бедных.
Кто редко видит мясо!  Полнокровной должна быть проверка что все
пакеты устанавливаются.  А проверка на анметы это паллиатив.

А Вы предлагаете делать пакеты, которые не имеют анметов, но которые
заведомо нельзя установить вследствие конфликтов.  Эта лавочка скоро
закроется.

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

Re: [devel] unmets policy - summary

[Igor Vlasenko]

On Wed, Sep 30, 2009 at 03:38:08AM +0400, Alexey Tourbin wrote:
> On Tue, Sep 29, 2009 at 09:29:33PM +0300, Igor Vlasenko wrote:
> > On Mon, Sep 28, 2009 at 10:34:33PM +0300, Michael Shigorin wrote:
> > > On Wed, Sep 23, 2009 at 07:17:07PM +0300, Igor Vlasenko wrote:
> > > > Предлагаю принять как временное полиси
> > > ack
> > Возражений не было, процедуры пройдены -
> > значит полиси принято. Завтра напишу анонс.
> 
> Возражения есть.  Проверка на анметы -- эта проверка для бедных.
> Кто редко видит мясо!  Полнокровной должна быть проверка что все
> пакеты устанавливаются.  А проверка на анметы это паллиатив.
> 
> А Вы предлагаете делать пакеты, которые не имеют анметов, но которые
> заведомо нельзя установить вследствие конфликтов.  Эта лавочка скоро
> закроется.

Алексей, возражение не принимаю, так как оно 
внутренне противоречиво.

"Нищим хлебушка не подаем, так как им нужно есть мясо!
А мяса не подаем, у нас самих его нет!"

Эта лавочка уже год как закрывается и закрывается.
А реально весь этот год приходилось мести unmets под ковер,
и Unmets Creation Policy --- описание, как это делать правильно.

Другими словами, пока карманов нет ---
 Unmets Creation Policy работало и будет работать,
так как альтернативы ему нет. Напишите альтернативу ---
тут же его упраздним. 
Так же и предлагалось -- упраздняется рабочей реализацией
карманов, в которых можно провести полноценный bootstrap.

А иначе это все лицемерие. Советские свадьбы,
где выдают желаемое за действительное.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] unmets policy - summary

[Alexey Tourbin]

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

On Wed, Sep 30, 2009 at 10:12:58AM +0300, Igor Vlasenko wrote:
> > Возражения есть.  Проверка на анметы -- эта проверка для бедных.
> > Кто редко видит мясо!  Полнокровной должна быть проверка что все
> > пакеты устанавливаются.  А проверка на анметы это паллиатив.
> > 
> > А Вы предлагаете делать пакеты, которые не имеют анметов, но которые
> > заведомо нельзя установить вследствие конфликтов.  Эта лавочка скоро
> > закроется.
> 
> Алексей, возражение не принимаю, так как оно 
> внутренне противоречиво.
> 
> "Нищим хлебушка не подаем, так как им нужно есть мясо!
> А мяса не подаем, у нас самих его нет!"
> 
> Эта лавочка уже год как закрывается и закрывается.
> А реально весь этот год приходилось мести unmets под ковер,
> и Unmets Creation Policy --- описание, как это делать правильно.

Сейчас не проверяется, что все пакеты устанавливаются, а со
временем будет проверяться что все пакеты устанавливаются (по
зависимостям).  У меня скрипт для апта есть но он сволочь долго
работает.  Время от времени думаю как его ускорить.

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

> Другими словами, пока карманов нет ---
>  Unmets Creation Policy работало и будет работать,
> так как альтернативы ему нет. Напишите альтернативу ---
> тут же его упраздним. 

Если есть два пакета, которые оба зависят друг от друга,
причем первый из них нужен для сборки второго, тогда помогает
в первом пакетов убрать зависимость на второй и/или написать
"AutoReq: yes, nofoo" (если зависимости появляются автоматически).
Это позволяет собрать второй пакет и провести задание в сизиф.  После
этого кляузу nofoo надо убрать и отправить пакет на сборку ещё раз.

То есть бутстрап штатно решается что в одном пакетов отключаются
requires-зависимости, до тех пор пока не появятся provides-зависимости.
Потом пакет собирают ещё раз, уже с requires-зависимостями.  К сожалению
это нельзя сделать в пределах одного задания.

> Так же и предлагалось -- упраздняется рабочей реализацией
> карманов, в которых можно провести полноценный bootstrap.
> 
> А иначе это все лицемерие. Советские свадьбы,
> где выдают желаемое за действительное.

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

Re: [devel] unmets policy - summary

[Igor Vlasenko]

On Wed, Sep 30, 2009 at 12:25:24PM +0400, Alexey Tourbin wrote:
> То есть возражение к полиси у меня что не надо делать искусственных
> конфликтов, которые делают установку пакетов с искусственным конфликтом
> заведомо невозможной.  Схема с искуственными конфликтами накроется как
> только заработает глобальная проверка на устанавливаемость.

Да, это принимается. 
Я поправил текст и убрал схему с искуственными конфликтами.
 
> > Другими словами, пока карманов нет ---
> >  Unmets Creation Policy работало и будет работать,
> > так как альтернативы ему нет. Напишите альтернативу ---
> > тут же его упраздним. 
> 
> Если есть два пакета, которые оба зависят друг от друга,
> причем первый из них нужен для сборки второго, тогда помогает
> в первом пакетов убрать зависимость на второй и/или написать
> "AutoReq: yes, nofoo" (если зависимости появляются автоматически).
> Это позволяет собрать второй пакет и провести задание в сизиф.  После
> этого кляузу nofoo надо убрать и отправить пакет на сборку ещё раз.
> 
> То есть бутстрап штатно решается что в одном пакетов отключаются
> requires-зависимости, до тех пор пока не появятся provides-зависимости.
> Потом пакет собирают ещё раз, уже с requires-зависимостями.  К сожалению
> это нельзя сделать в пределах одного задания.

Эта схема в каких-то случаях будет работать, но она 
1) так же опасна, как и в полиси с убранными искуственными конфликтами
(пользователь может обновиться до разломанного состояния)
2) намного более громоздкая чем предложенная,
что в ряде случаев полностью исключает ее практическое применение.

Например, я обновляю maven2. Выкладываю bootstrap maven'a 2,
с минимальным набором плагинов, потом собираю все более полный
набор.

Но! whoreq maven2-plugin-*
acegi-security-1.0.7-alt1_2jpp5.ёsrc|maven2-plugin-antrun
acegi-security-1.0.7-alt1_2jpp5.src|maven2-plugin-assembly
...
xsite-1.0-alt3_0.b9.1jpp5.src|maven2-plugin-surefire
xsite-1.0-alt3_0.b9.1jpp5.src|maven2-plugin-surefire-report

whoreq maven2-plugin-* | wc -l
1311

на 3 порядка легче подмешать один пакет unmet-dependency-maven2,
чем изымать из репозитария 1311 requires, а потом добавлять.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] unmets policy - summary

[Денис Смирнов]

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

On Wed, Sep 30, 2009 at 12:25:24PM +0400, Алексей Турбин wrote:

AT> То есть возражение к полиси у меня что не надо делать искусственных
AT> конфликтов, которые делают установку пакетов с искусственным конфликтом
AT> заведомо невозможной.  Схема с искуственными конфликтами накроется как
AT> только заработает глобальная проверка на устанавливаемость.

Вы бы сначала реализовали все-таки pocket'ы. Или хотя бы те самые task'и с
перестроением репозитория внутри task'а.

Потому что bootstrap по своей природе _требует_ создания промежуточных
репозиториев, которые по своей сути являются "сломанными".

AT> То есть бутстрап штатно решается что в одном пакетов отключаются
AT> requires-зависимости, до тех пор пока не появятся provides-зависимости.
AT> Потом пакет собирают ещё раз, уже с requires-зависимостями.  К сожалению
AT> это нельзя сделать в пределах одного задания.

Алексей, есть ли причины не позволять это делать внутри одного task'а, с
помощью предложенной мной команды перестроения временного репозитория?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] unmets policy - summary

[Igor Vlasenko]

Unmets:
Таким образом, если больше возражений/дополнений нет,
то полиси принято, как временное, до появления карманов.

Если сам факт наличия такого полиси вдохновит кого-нибудь
на полноценные карманы с bootstrap, то оно писалось не зря :)

On Wed, Sep 30, 2009 at 11:52:32AM +0300, Igor Vlasenko wrote:
> On Wed, Sep 30, 2009 at 12:25:24PM +0400, Alexey Tourbin wrote:
> > То есть возражение к полиси у меня что не надо делать искусственных
> > конфликтов, которые делают установку пакетов с искусственным конфликтом
> > заведомо невозможной.  Схема с искуственными конфликтами накроется как
> > только заработает глобальная проверка на устанавливаемость.
> 
> Да, это принимается. 
> Я поправил текст и убрал схему с искуственными конфликтами.
-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine