[devel] пакеты копировать нельзя

[devel] пакеты копировать нельзя

[Alexey Tourbin]

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

Нельзя копировать собранные пакеты из одного репозитария
в другой (напр. между sisyphus и 5.0).

Сборку пакета можно (и нужно) рассматривать как процесс,
который реализует функцию

B(S,C)->P

где
B - процедура сборки (реализуется хешером),
S - src.rpm пакет с исходным кодом,
С - содержимое сборочной среды.

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

Распишем подробнее C.  Пусть

U - полный набор пакетов в репозитарии (универсум пакетов).

Тогда среда C для сборки пакета S - это

C = C(S,U) = C0(U) + C1(S,U)

где

C0 - процедура инициализации базового сборочного чрута (и соответствующий
список пакетов в базовом сборочном чруте),
C1 - процедура установки в базовый сборочный чрут дополнительных
зависимостей BuildRequires пакета S (и соответствующий список пакетов,
который является замыканием зависимостей BuildRequires пакета S).

Если один и тот же пакет с исходным кодом S был собран в разных средах
Ca и Cb, то необходимо считать, что результат сборки отличается:

B(S,Ca)->Pa
B(S,Cb)->Pb
Ca!=Cb => Pa!=Pb

Принцип "B(S,C)->P" ложится в основу модели данных репозитария с
условным названием "метерепозитарий".  Метарепозитарий должен точно
описывать историю развития репозитария и изменения всех его
характеристик.  История метарепозитария описывается в терминах
"коммитов".  Коммит описывает прохождение одного нового пакета
в репозитарий, используя набор данных (S,C0,C1,P).  (Если в задание
добавлено несколько пакетов на сборку, а не один пакет, то будет
несколько таких наборов данных; коммит соответствует транзакции,
а задания проводятся транзакционно).  То есть история изменения
репозитария описывается в терминах коммитов, которые фиксируют
характеристики исходного пакета для сборки, характеристики базовой
сборочной среды C0 и дополнительных пакетов C1 из BuildReuires,
и характеристики собранных пакетов.

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

Ub = Ua + P.

Если данный пакет был собран на универсуме Ua, то следующий пакет уже
будет собран на другом универсуме - Ub.

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

Вообще, не существует пакетов в отрыве от той среды, в которой они были
собраны, и, значит, в отрыве от истории репозитария.  Нельзя войти в
одну реку дважды.

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

Re: [devel] пакеты копировать нельзя

[Dmitriy M. Maslennikov]

16 февраля 2009 г. 12:28 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> ...
Такие рассуждения выглядят красиво. Но если оторваться от чистой
математики и вернуться к практике, то, на мой взгляд, все выглядит
несколько иначе.

Мне, как и большинству пользователей важен репозиторий в первую
очередь РАБОТАЮЩИЙ. То есть с работающими на практике пакетами.
Обеспечить это можно только полноценным тестированием пакетов ДО
помещения их в основной репозиторий. При этом полной гарантии дать,
конечно, нельзя, но в целом пакет, прошедший тестирование, гораздо
более надежен, чем тот, который не проверялся вообще. Все рассуждения
данные выше направлены не на это свойство, а на гарантию повторяемости
процесса сборки пакета. С точки зрения удобства ведения репозитория
это, конечно полезно, но для пользователя репозитория это совсем не
так важно. Так, для пользователя отлично пересобирающийся, но не
работающий новый пакет foo-0.1-alt1 гораздо хуже не способного
пересобраться, но РАБОТАЮЩЕГО пакета foo-0.1-alt1. Еще же интереснее
гарантировать и пересобираемость, и работоспособность пакетов.

Когда мы думали над похожей тематикой, мы решили пожертвовать
сериализацией сборки пакетов (сборка пакета A -> добавление пакета A в
репозитарий -> сборка пакета B), разрешив  прошедшим сборку пакетам
временно попадать в тестовый репозиторий. И только после этапа
тестирования пакеты попадают в основной репозиторий (если не порождают
unmet'ов и проходят прочие проверки). При этом таких тестовых
репозиториев можно создавать сколько угодно (для каждой задачи свой
отдельный репозиторий - box). В каждый можно собирать пакеты,
основываясь на текущем состоянии репозитория и состоянии самого box'а.
При этом принятие пакетов из box'а в репозитарий происходит по
завершению тестирования сериализованно (атомарно).

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

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] пакеты копировать нельзя

[Evgeny Sinelnikov]

16 февраля 2009 г. 23:52 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> 16 февраля 2009 г. 12:28 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> ...
> ...

К странным выводам прихожу я... Если пакет есть функция

B(S,C)->P,

где B - процедура сборки, S - src.rpm пакет, а С - сборочная среда

C = C(S,U) = C0(U) + C1(S,U)

где C0 - процедура инициализации базового сборочного чрута, C1 -
процедура установки в базовый сборочный чрут дополнительных
зависимостей BuildRequires пакета S.

То кроме сборки пакета с исходным кодом S в разных средах Ca и Cb,
можно вести речь о сборке разных пакетов на одной и той же сборочной
среде

B(Sа,Ca)->Pa
B(Sb,Cb)->Pb

где

Ca = Ca(Sa,U) = C0(U) + C1(Sa,U)
Cb = Cb(Sb,U) = C0(U) + C1(Sb,U)

При этом вовсе не обязательно, что эволюция универсума пакетов будет
приводить к неповторяемости:

Ca = Ca(Sa,U) ? Ca' = Ca(Sa,Ub)
Cb = Ca(Sb,U) ? Cb' = Cb(Sb,Ua)

где

M(U,Pa)->Ua
M(U,Pb)->Ub

где

M - процедура объединения нового пакета в универсум пакетов
Ua - универсум пакетов с новой сборкой пакета Pa
Ub - универсум пакетов с новой сборкой пакета Pb

То есть ответ на вопрос о не равенствах Ca и Ca', а также Cb и Cb',
зависит от вхождения исходных вариантов пакетов Pa^ и Pb^ в из U в
сборочные среды Cb и Ca для сборки пакетов Pb и Pa соответственно.

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

В плане же перекладывания можно пойти дальше. Процедура B определяет
пересобираемость пакета на предыдущем универсуме пакетов, но ничего не
говорит о последующих, а, самое главное, совсем ничего не говорит о
работоспособности ни на каком из них. Работоспособность же
определяется тестированием (числом проявившихся отказов). Так вот
компромисс между потерей целостности истории репозитория и времени
потраченного на тестирование предыдущей сборки одного и того же пакета
нужно решать аккуратно. Иначе мы рискуем, получив полную историю,
всегда терять время потраченное нами самими на тестирование разных
сборок (в разных сборочных средах) одних и тех же пакетов...


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] пакеты копировать нельзя

[Alexey Tourbin]

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

On Mon, Feb 16, 2009 at 11:52:55PM +0300, Dmitriy M. Maslennikov wrote:
> 16 февраля 2009 г. 12:28 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> > ...
> Такие рассуждения выглядят красиво. Но если оторваться от чистой
> математики и вернуться к практике, то, на мой взгляд, все выглядит
> несколько иначе.

Практические следствия модели могут быть ещё не вполне ясны.
Они проявятся при внедрении тестовой пересборки пакетов.

> Мне, как и большинству пользователей важен репозиторий в первую
> очередь РАБОТАЮЩИЙ. То есть с работающими на практике пакетами.

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

Пусть пакет A был собран в родной среде, и потом идёт пакет B.
Тогда идёт тесовая пересборка репозитария с пакетом B, в том числе
пересобирается пакет A.  Если у тестово-пересобранного пакета A
изменились зависимости, то это изменение зависимостей можно однозначно
квалифицировать как влияние пакета B.  Если же пакет A и вовсе перестал
собираться, тогда можно однозначно утверждать, что пакет B ломает
сборку пакета A.

Всё это пропадает, если пакет A был собран где-то ещё.  Тогда ни
изменение зависимостей у пакета A, и ни поломку сборки пакета A
уже нельзя однозначно связать с влиянием пакета B.

> Обеспечить это можно только полноценным тестированием пакетов ДО
> помещения их в основной репозиторий. При этом полной гарантии дать,
> конечно, нельзя, но в целом пакет, прошедший тестирование, гораздо
> более надежен, чем тот, который не проверялся вообще. Все рассуждения
> данные выше направлены не на это свойство, а на гарантию повторяемости
> процесса сборки пакета. С точки зрения удобства ведения репозитория
> это, конечно полезно, но для пользователя репозитория это совсем не
> так важно. Так, для пользователя отлично пересобирающийся, но не
> работающий новый пакет foo-0.1-alt1 гораздо хуже не способного
> пересобраться, но РАБОТАЮЩЕГО пакета foo-0.1-alt1. Еще же интереснее
> гарантировать и пересобираемость, и работоспособность пакетов.

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

> Когда мы думали над похожей тематикой, мы решили пожертвовать
> сериализацией сборки пакетов (сборка пакета A -> добавление пакета A в
> репозитарий -> сборка пакета B), разрешив  прошедшим сборку пакетам
> временно попадать в тестовый репозиторий.

Это мелкое мошенничество.  Если нет сериализации, то нельзя
зафиксировать взаимное влияние между пакетами.  А если нельзя
зафиксировать взаимное влияние между пакетами, тогда нельзя однозначно
сказать, какой пакет ломает другие пакеты (или вообще "плохо влияет").

Тогда мы возвращаемся к старой модели incoming + еженедельная тестовая
пересборка сизифа.  Всю неделю создается "временный репозитарий", а в
конце недели идёт "тестовая пересборка".  Но по результатам тестовой
пересборки уже нельзя однозначно определить, кто кого сломал.  А модель
с сериализацией позволяет точно определить, кто кого сломал, и, более
того, реализовать pre-condition: не пропускать пакеты, которые что-то
ломают.

> И только после этапа
> тестирования пакеты попадают в основной репозиторий (если не порождают
> unmet'ов и проходят прочие проверки). При этом таких тестовых
> репозиториев можно создавать сколько угодно (для каждой задачи свой
> отдельный репозиторий - box). В каждый можно собирать пакеты,
> основываясь на текущем состоянии репозитория и состоянии самого box'а.
> При этом принятие пакетов из box'а в репозитарий происходит по
> завершению тестирования сериализованно (атомарно).

В терминах girar-builder получается, что box -- это задание (task).
В задании может быть несколько пакетов.  То есть в принципе можно
"варить" некоторый набор изменений сколько угодно (то есть дорабатывать
пакеты, если обнаруживаются ухудшения).  Задание применяется
транзакционно.  В girar-builder будет реализована довольно сложная 
стратегия мёржа, которая должна отвечать за окончательную сериализацию
задания.  Стратегия мёржа "применяет" задание к репозитарию.  В
зависимости от некоторых базовых условий, стратегию мержа можно
реализовать немного по-разному.  В частности, мёрж может подразумевать,
что перед помещением пакетов задания в репозитарий их нужно заново
пересобрать.  Короче, сериализация возможна, хотя это не очень просто.

[И ещё, к счастью, сериализация заданий -- это головная боль отдельно
взятого человека.]

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

Мне не очень понятно, что такое "непосредственное тестирование".
То есть это значит ставить пакеты на рабочую машину, запускать программы
и смотреть, работают они или не работают?  Это не технологично, а при
числе пакетов порядка 10^4 это вряд ли возможно.

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

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

Как получить "работающие пакеты"?  Например, у меня f-spot через
некоторое время после запуска, всё время разное, вываливается со
stack trace.  Что можно предпринять по части технологии сборки пакетов,
чтобы f-spot "работал"?  То есть он даже запускается, если вручную
проверять, а потом падает.  В этом смысле говорить про "работающие
пакеты" мне кажется не очень конструктивно.

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

Re: [devel] пакеты копировать нельзя

[Evgeny Sinelnikov]

17 февраля 2009 г. 10:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Mon, Feb 16, 2009 at 11:52:55PM +0300, Dmitriy M. Maslennikov wrote:
>> 16 февраля 2009 г. 12:28 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> > ...
>> ...

[...]

>> И только после этапа
>> тестирования пакеты попадают в основной репозиторий (если не порождают
>> unmet'ов и проходят прочие проверки). При этом таких тестовых
>> репозиториев можно создавать сколько угодно (для каждой задачи свой
>> отдельный репозиторий - box). В каждый можно собирать пакеты,
>> основываясь на текущем состоянии репозитория и состоянии самого box'а.
>> При этом принятие пакетов из box'а в репозитарий происходит по
>> завершению тестирования сериализованно (атомарно).
>
> В терминах girar-builder получается, что box -- это задание (task).
> В задании может быть несколько пакетов.  То есть в принципе можно
> "варить" некоторый набор изменений сколько угодно (то есть дорабатывать
> пакеты, если обнаруживаются ухудшения).  Задание применяется
> транзакционно.  В girar-builder будет реализована довольно сложная
> стратегия мёржа, которая должна отвечать за окончательную сериализацию
> задания.  Стратегия мёржа "применяет" задание к репозитарию.  В
> зависимости от некоторых базовых условий, стратегию мержа можно
> реализовать немного по-разному.  В частности, мёрж может подразумевать,
> что перед помещением пакетов задания в репозитарий их нужно заново
> пересобрать.  Короче, сериализация возможна, хотя это не очень просто.
>

А доступен ли извне task, как временный тестовый репозиторий? Я думаю,
что именно это его сейчас отличает от понятия box. Если нет такого
временного аналога Deadalus, то я не понимаю как протестировать пакет
кроме как локально... А ведь, в ряде случаев, в его тестировании
заинтересован не только сам мейнтейнер...

> [И ещё, к счастью, сериализация заданий -- это головная боль отдельно
> взятого человека.]
>

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

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

Возникло предложение. А действительно, можно ли организовать
доступность извне task'ов, как временных тестовых репозиториев?

[..]

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] пакеты копировать нельзя

[Anton Farygin]

Evgeny Sinelnikov пишет:
> 17 февраля 2009 г. 10:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
<skip>
> 
> Возникло предложение. А действительно, можно ли организовать
> доступность извне task'ов, как временных тестовых репозиториев?

+1. Желательно с возможностью добавлять subtask'и

Re: [devel] пакеты копировать нельзя

[Alexey Tourbin]

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

On Tue, Feb 17, 2009 at 11:03:32AM +0300, Evgeny Sinelnikov wrote:
> А доступен ли извне task, как временный тестовый репозиторий? Я думаю,
> что именно это его сейчас отличает от понятия box. Если нет такого

Задания выкладываются в git.altlinux.org, и задания содержат собранные
пакеты.  Например, http://git.altlinux.org/tasks/1108/build/1/i586/rpms/

То есть apt/hasher репозитария в задании нет, но это относительно
несложно сделать самому.  Можно делать и в задании.  Это сейчас не
делается по определенной причине: два репозитария, Sisyphus + RPMS.hasher,
это не то же самое, что новый репозитарий Sisyphus, в котором были
корректно обновлены пакеты RPMS.hasher.  То есть некоторый класс проблем
нельзя обнаружить, используя RPMS.hasher-оверлей поверх текущего сизифа,
а можно только обнаружить, целиком сформировав новый репозитарий (без
дупов и т.д.).

> временного аналога Deadalus, то я не понимаю как протестировать пакет
> кроме как локально... А ведь, в ряде случаев, в его тестировании
> заинтересован не только сам мейнтейнер...

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

Кажется, Дмитрий добавил в girar-task какой-то manual режим, который
делает примерно это (выполняет все стадии сборки и тестирования, но не
выполняет стадии "коммитов").  Я ещё не понял, как им пользоваться.

Но, строго говоря, нельзя полагаться на то, что в сизиф пойдут именно
те пакеты, которые сейчас лежат в tasks/$id/build/ и которые Вы
протестировали.  Когда Вы дадите добро на перемещение протестированных
пакетов в сизиф, girar-builder по своим внутренним соображениям может
пересобрать эти пакеты ещё раз (на новом репозитарии).  Тогда у Вас
в системе будут стоять не те же самые пакеты, которые попадут в Сизиф.
И dist-upgrade работать не будет, потому что EVR останется прежним.

[Внутреннее соображение у girar-builder может быть только одно:
если на свежем репозитарии содержимое сборочной среды C изменилось,
то girar-builder имеет право заново пересобрать соответствующие исходные
пакеты S.]

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

> > [И ещё, к счастью, сериализация заданий -- это головная боль отдельно
> > взятого человека.]
> 
> К сожалению, мы пока не пробовали обновить таким образом, например
> boost, и не встречались с задачей починить все пакеты, которые
> сломались или протестировать пакеты, которые могли сломаться силами
> тех, кто в этом заинтересован. А головная боль, при этом, всё равно
> остаётся, если даже проверить нельзя будущую сборку пакета, от
> которого зависят другие, пока все они разом не соберутся... Можно все,
> конечно, локально собрать, но это ведь не то, что стоит повторять для
> проверки...

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

Зато мы можем декларировать принцип: репозитарий можно переводить только
из одного целостного состояние в другое целостное (точнее, не менее
целостное) состояние, определяемое по ряду формальных признаков (грубо
говоря, формальных признаков всего два: устанавливаемость пакетов и
пересобираемость пакетов).  Значит, мы всегда имеем репозитарий по
крайней мере в формально неплохом состоянии.  А это решает часть
проблем, которые мы до сих пор имеем.

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

Можно.

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

Re: [devel] пакеты копировать нельзя

[Dmitry V. Levin]

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

On Tue, Feb 17, 2009 at 12:01:27PM +0300, Alexey Tourbin wrote:
[...]
> Кажется, Дмитрий добавил в girar-task какой-то manual режим, который
> делает примерно это (выполняет все стадии сборки и тестирования, но не
> выполняет стадии "коммитов").  Я ещё не понял, как им пользоваться.

Никак, это пока "мысли в коде".


-- 
ldv

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

Re: [devel] пакеты копировать нельзя

[Dmitriy M. Maslennikov]

17 февраля 2009 г. 10:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> ...
Можно придумать и компромисный вариант. Для каждой сборки пакета можно
сохранять его сборочное окружение C, как список установленных в hasher
при сборке пакетов. Все, собранные в рамках одного task, пакеты
кладутся в box и могут тестироваться добровольцами/уполномоченными
тестерами. После того, как принято решение о принятии пакетов и
task'а, можно выполнить контрольную пересборку и сравнить полученные
сборочные окружения для новых сборок. Если они совпали с окружениями
при получении тестируемых пакетов, то принимаем изменения, если нет,
то пакеты надо тестировать повторно, так как они уже изменились. Таким
образом имеем и сериализацию сборки и поступления пакетов в
репозиторий и возможность проводить тестирование пакетов до их
попадания в финальный репозиторий. При этом принимать надо (ИМХО)
именно протестированные бинарии, на случай возможных ошибок при сборке
из-за сбоев аппаратуры (битая память или еще что), что не
формализуется, а вот на реальной работоспособности пакета может
сказаться.

Как вам такой вариант?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] пакеты копировать нельзя

[Kirill A. Shutemov]

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

On Tue, Feb 17, 2009 at 12:01:27PM +0300, Alexey Tourbin wrote:
> On Tue, Feb 17, 2009 at 11:03:32AM +0300, Evgeny Sinelnikov wrote:
> > А доступен ли извне task, как временный тестовый репозиторий? Я думаю,
> > что именно это его сейчас отличает от понятия box. Если нет такого
> 
> Задания выкладываются в git.altlinux.org, и задания содержат собранные
> пакеты.  Например, http://git.altlinux.org/tasks/1108/build/1/i586/rpms/
> 
> То есть apt/hasher репозитария в задании нет, но это относительно
> несложно сделать самому.  Можно делать и в задании.  Это сейчас не
> делается по определенной причине: два репозитария, Sisyphus + RPMS.hasher,
> это не то же самое, что новый репозитарий Sisyphus, в котором были
> корректно обновлены пакеты RPMS.hasher.  То есть некоторый класс проблем
> нельзя обнаружить, используя RPMS.hasher-оверлей поверх текущего сизифа,
> а можно только обнаружить, целиком сформировав новый репозитарий (без
> дупов и т.д.).

А нельзя ли в задании формировать локальный Сизиф с корректно внесёнными
изменениями? Или сделать это с приемлимыми издержками не представляется
возможным?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

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

Re: [devel] пакеты копировать нельзя

[Dmitry V. Levin]

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

On Wed, Feb 18, 2009 at 01:49:42AM +0200, Kirill A. Shutemov wrote:
> On Tue, Feb 17, 2009 at 12:01:27PM +0300, Alexey Tourbin wrote:
> > On Tue, Feb 17, 2009 at 11:03:32AM +0300, Evgeny Sinelnikov wrote:
> > > А доступен ли извне task, как временный тестовый репозиторий? Я думаю,
> > > что именно это его сейчас отличает от понятия box. Если нет такого
> > 
> > Задания выкладываются в git.altlinux.org, и задания содержат собранные
> > пакеты.  Например, http://git.altlinux.org/tasks/1108/build/1/i586/rpms/
> > 
> > То есть apt/hasher репозитария в задании нет, но это относительно
> > несложно сделать самому.  Можно делать и в задании.  Это сейчас не
> > делается по определенной причине: два репозитария, Sisyphus + RPMS.hasher,
> > это не то же самое, что новый репозитарий Sisyphus, в котором были
> > корректно обновлены пакеты RPMS.hasher.  То есть некоторый класс проблем
> > нельзя обнаружить, используя RPMS.hasher-оверлей поверх текущего сизифа,
> > а можно только обнаружить, целиком сформировав новый репозитарий (без
> > дупов и т.д.).
> 
> А нельзя ли в задании формировать локальный Сизиф с корректно внесёнными
> изменениями? Или сделать это с приемлемыми издержками не представляется
> возможным?

Такой временный репозиторий для каждого задания создаётся, он необходим
для вычисления разных проверок.  Наверное, вопрос был не в этом?


-- 
ldv

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

Re: [devel] пакеты копировать нельзя

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

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

On Thu, Feb 19, 2009 at 02:32:41AM +0300, Dmitry V. Levin wrote:

>> А нельзя ли в задании формировать локальный Сизиф с корректно внесёнными
>> изменениями? Или сделать это с приемлемыми издержками не представляется
>> возможным?
DVL> Такой временный репозиторий для каждого задания создаётся, он необходим
DVL> для вычисления разных проверок.  Наверное, вопрос был не в этом?

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

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

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

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

Re: [devel] пакеты копировать нельзя

[Kirill A. Shutemov]

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

On Thu, Feb 19, 2009 at 02:32:41AM +0300, Dmitry V. Levin wrote:
> On Wed, Feb 18, 2009 at 01:49:42AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Feb 17, 2009 at 12:01:27PM +0300, Alexey Tourbin wrote:
> > > On Tue, Feb 17, 2009 at 11:03:32AM +0300, Evgeny Sinelnikov wrote:
> > > > А доступен ли извне task, как временный тестовый репозиторий? Я думаю,
> > > > что именно это его сейчас отличает от понятия box. Если нет такого
> > > 
> > > Задания выкладываются в git.altlinux.org, и задания содержат собранные
> > > пакеты.  Например, http://git.altlinux.org/tasks/1108/build/1/i586/rpms/
> > > 
> > > То есть apt/hasher репозитария в задании нет, но это относительно
> > > несложно сделать самому.  Можно делать и в задании.  Это сейчас не
> > > делается по определенной причине: два репозитария, Sisyphus + RPMS.hasher,
> > > это не то же самое, что новый репозитарий Sisyphus, в котором были
> > > корректно обновлены пакеты RPMS.hasher.  То есть некоторый класс проблем
> > > нельзя обнаружить, используя RPMS.hasher-оверлей поверх текущего сизифа,
> > > а можно только обнаружить, целиком сформировав новый репозитарий (без
> > > дупов и т.д.).
> > 
> > А нельзя ли в задании формировать локальный Сизиф с корректно внесёнными
> > изменениями? Или сделать это с приемлемыми издержками не представляется
> > возможным?
> 
> Такой временный репозиторий для каждого задания создаётся, он необходим
> для вычисления разных проверок.  Наверное, вопрос был не в этом?

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

Хочется аналог ssh git.alt task run, который в случае успеха не приводит к
слиянию с основным репозиторием, а лишь генерирует репозиторий (Сизиф или
бранч) с корректно внесёнными изменениями и выкладывает куда-то в
http://git.altlinux.org/tasks/

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

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