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'ов, как временных тестовых репозиториев?

Можно.