Re: Генерация pool-based репозиториев
On Sun, 3 Mar 2019 15:32:47 +0300
Eugene Berdnikov <bd4@protva.ru> wrote:
> On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:
> Возможно, конкретно для reprepro проблемы нет, но в общем случае
> лучше делать репозиторий локальным, а с облаком синхронизовать после
> успешного завершения всех локальных транзакций, т.е. когда всё уже в
> файлах и в консистентном виде. Сохранить целостность при передаче в
> облако несложно, но это так лишь потому, что технология отработана --
> авторы rsync/etc тщательно продумали все возможные сценарии сбоев, и
> мы этим пользуемся.
C сохранением консистентности конкретно у репозиториев есть
определенные проблемы.
Я давно не смотрел на современные средства мирроринга репозиториев, но
когда мне это было надо, при мирроре возникала
проблема, что целевой миррор может оказаться неконсистентным пока
работа миррорящего скрипта не закончена.
Чтобы миррор всегда был консистентным, необходимо действовать в
следующей последовательности:
1. Сначала скачать все новые пакеты
2. Потом скопировать Packages{,.gz,.bz2} Release и Release.gpg и
единомоментно атоммарной операцией из заменить.
3. Удалить более ненужные пакеты.
А rsync --delete делает не так. Он СНАЧАЛА удаляет более ненужные
файлы, а потом уже копирует новые. Ну и о том, что Release содержит
контрольную сумму Packages и менять их нужно одновременно - тоже не в
курсе.
Отдельное развлечение случается когда у тебя параллельно работает
десяток jenkins-овских заданий, собирающих разные пакеты, зависящие
друг от друга. Может запросто получиться так, что задание 1 сделало
apt-get update, потом задание 2 выложило новую версию своего пакета
и перергенерировало packages, а потом задание 1 захотело этот пакет
поставить, потому что он у него Build-Depends.
Прикрутить туда осмысленную систему exclusive и shared блокировок при
условии того, что задания крутятся на куче разных машин и в репозиторий
ходят apt-ом весьма нетривиально.
--
Reply to: