[devel] задания и схемы совместной работы

Денис Смирнов =?iso-8859-1?q?mithraen_=CE=C1_altlinux=2Eru?=
Пт Фев 27 04:24:05 MSK 2009


On Thu, Feb 26, 2009 at 07:10:23PM +0300, Алексей Турбин wrote:

>> Об этом и речь.
>> Как это реально будет выглядеть?
>> Будет ли это похоже на pocket, о котором говорил Денис?
AT> Я не знаю, что такое pocket, это не было строго описано.

Описываю.

Pockets это некоторый репозиторий, который строится на базе среза сизифа на
определенный момент времени (момент создания pocket'а) и пакетов которые
были собраны в рамках этого task.

Его особенности:

- пригоден для работы apt-get (в отличии от task'а);
- в него после начала работы можно добавлять, удалять пакеты, и вообще
  вести себя с ним как с еще одним репозиторием на равных правах с двумя
  уже имеющимся в girar (создавать новые task'и, копировать пакеты, и
  т.д.);
- этот репозиторий, в отличии от "обычных" не гарантирует отсутствия
  unmet'ов, возможно какие-либо другие проверки тоже в нем будут
  отключены;
- в любой момент времени можно дать команду "rebase" -- это попытка
  сделать rebase на последнее состояние репозитория, из которого делался
  pocket;
- в любой момент можно дать команду "commit" -- в этом случае все
  изменения в этом pocket'е попытаются примениться как один единый task к
  Сизифу, в случае неудачи -- соответственно будет лог об ошибках и
  возможность доработать pocket для того чтобы его можно было безопасно
  заcommit'ить;

Логика выполнения commit:
- блокировать все пользовательские операции в этом pocket
- сделать rebase (речь не о git rebase, разумеется, а о том что в репо
  находится свежий сизиф + все измененные пакеты - все удаленные пакеты в
  этом pocket);
- повторно пересобрать все пакеты внутри этого pocket (для гарантии
  собираемости);
- выполнить _копирование_ пакетов в Сизиф;

Необходимость копирования объясняется именно возможностью выполнения
bootstrap'ов всяких. После цепочки изменений которая происходит внутри
pocket'а не гарантируется что хоть один пакет из pocket вообще возможно
собрать в исходном репозитории;

AT> В общем, есть как бы pockets, но с достаточно жесткими условиями
AT> по части кто за что отвечает.

От pockets это отличается тем, что внутри задания невозможно выполнить
процедуры вроде замены одного пакета другим (del и создание нового пакета
с тем же именем), а также невозможно последовательно выполнить несколько
сборок одного и того же пакета.

Также task'и сейчас не являются полноценными доступными извне
репозиториями.

AT> Какие ещё схемы можно придумать, чтобы людям было проще договориться?

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

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090227/ce90a832/attachment-0001.bin>


Подробная информация о списке рассылки Devel