Генерация pool-based репозиториев

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Генерация pool-based репозиториев

Victor Wagner-2
Коллеги,

А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
reprepro?

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

Хотелось бы чего-нибудь более простого и низкоуровневого, чему
указал списко пакетов, а оно и сгенерило для них packages, вроде
dpkg-scanpackages, но из докуменации и на dpkg-scanpackages, и на
apt-ftparchive я не смог вычитать как ими работать с pool-based
репозиториями, а не с репозиториями старого образца, где пакеты лежат
непосредственно в dists/${codename}/main/binary-${arch}.

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



--


Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Tim Sattarov
On 2/26/19 4:24 AM, Victor Wagner wrote:
> Коллеги,
>
> А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> reprepro?
я использую для этого aptly

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Victor Wagner-2
В Tue, 26 Feb 2019 11:16:38 -0500
Tim Sattarov <[hidden email]> пишет:

> On 2/26/19 4:24 AM, Victor Wagner wrote:
> > Коллеги,
> >
> > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> > reprepro?  
> я использую для этого aptly

Штука еще более высокоуровневая и навороченная, чем reprepro.
Обладает  тем же нредостатком - хочет испольовать какую-то левую базу
данных.


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

Ну и добавлять пакеты в репозиторий можно не только на основании файлов
changes, но и отдельными .deb и .dsc. А здесь я этого как-то не увидел.

Я помнится, в reprepro  .changes-файлами намучался, когда мне
потребовалось поддерживать всего-то три архитектуры.






--
                                   Victor Wagner <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Victor Wagner-2
In reply to this post by Tim Sattarov
В Tue, 26 Feb 2019 11:16:38 -0500
Tim Sattarov <[hidden email]> пишет:

> On 2/26/19 4:24 AM, Victor Wagner wrote:
> > Коллеги,
> >
> > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> > reprepro?  
> я использую для этого aptly
>

Снапшоты в aptly, конечно, замечательная штука. Но оно же не умеет ни
yum, ни apt-rpm, а использовать для одних дистрибутивов один механизм
снапшотов а для других - другой крайне неудобно.


--
                                   Victor Wagner <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

sergio-3
In reply to this post by Victor Wagner-2
On 26/02/2019 12:24, Victor Wagner wrote:

> А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
> reprepro?

https://wiki.debian.org/DebianRepository/Setup#mini-dak ?

Просто нагуглил, сам не пробовал.

--
sergio.

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Igor Savlook
In reply to this post by Victor Wagner-2


On 26/02/2019 22.57, Victor Wagner wrote:

> В Tue, 26 Feb 2019 11:16:38 -0500
> Tim Sattarov <[hidden email]> пишет:
>
>> On 2/26/19 4:24 AM, Victor Wagner wrote:
>>> Коллеги,
>>>
>>> А чем в наше время можно генерировать pool-based репозитории, КРОМЕ
>>> reprepro?
>> я использую для этого aptly
>
> Штука еще более высокоуровневая и навороченная, чем reprepro.
> Обладает  тем же нредостатком - хочет испольовать какую-то левую базу
> данных.
>
Для твоих запросов тебе всеравно прийдется использовать утилиту с бд.
Без них нет утилит. Можеш поставить dak там вообще postgresql. В
документации я так понял ты про архитектуру не читал и зачем эти утилиты
юзают бд ты смотрел?

>
> У того хотя бы нет глобального (уровня юзера) конфигурационного
> файла и каждый репозиторий, в каком бы месте файловой системы он не
> находился, абсолютно незевисим.
>
> Ну и добавлять пакеты в репозиторий можно не только на основании файлов
> changes, но и отдельными .deb и .dsc. А здесь я этого как-то не увидел.
>
> Я помнится, в reprepro  .changes-файлами намучался, когда мне
> потребовалось поддерживать всего-то три архитектуры.
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Victor Wagner
В Sat, 2 Mar 2019 11:52:55 +0300
Igor Savluk <[hidden email]> пишет:

> On 26/02/2019 22.57, Victor Wagner wrote:
> > В Tue, 26 Feb 2019 11:16:38 -0500
> > Tim Sattarov <[hidden email]> пишет:
> >  
> >> On 2/26/19 4:24 AM, Victor Wagner wrote:  
> >>> Коллеги,
> >>>
> >>> А чем в наше время можно генерировать pool-based репозитории,
> >>> КРОМЕ reprepro?  
> >> я использую для этого aptly  
> >
> > Штука еще более высокоуровневая и навороченная, чем reprepro.
> > Обладает  тем же нредостатком - хочет испольовать какую-то левую
> > базу данных.
> >  
> Для твоих запросов тебе всеравно прийдется использовать утилиту с бд.


База данных - это не единственное средство организовать дурацкий поиск.
Вообще говоря, в deb-файле содержится более чем достаточно информации,
чтобы сгенерировать Packages file entry.

Я на самом деле уже выяснил, что apt-ftparchive generate при правильно
описанном конфиге мою задачу решает. Ну или почти решает. Во всяком
случае текстового filelist хватит для того, чтобы заменить базу данных.

Поскольку единственная информация, которая не извлекается однозначно из
самого пакета - это к какому suite он относится (и  это сделано
намеренно, потому что пакеты мигрируют из unstable в testing, testing
превращается в stable, a stable в oldstable, а некоторые пакеты
по-моему не пересобираются релиза по четыре).


> Без них нет утилит. Можеш поставить dak там вообще postgresql. В

Только у криворуких идиотов.

> документации я так понял ты про архитектуру не читал и зачем эти
> утилиты юзают бд ты смотрел?

Потому что это вообще традиция современной IT. Нужно сайт, который
обновляется через веб-интерфейс - лепят туда базу данных, нужно хранить
закладки в браузере - лепят туда sqlite.

Более того, пользоваться базами  данных эти  криворукие идиоты тоже не
умеют, о referential integrity, например, вообще обычно не слышали и
чем 2 НФ от 4 отличаются не в курсе.

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

Но мне-то нужно от силы пара десятков пакетов, зато под 30
дистрибутивов, далеко не все из которых Debian и Ubuntu (отдельная
призовая игра - это astra, которая использует deb-пакеты и apt, но при
этом у нее codename означает вовсе не версию и для разных codename
может быть разная политика версионирования).

Поэтому если уж заводить базу данных, то ее надо заводить для всего
этого хозяйства. а не отдельно для Debian, отдельно для Ubuntu.
отдельно для RHEL.



--
                                   Victor Wagner <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Tim Sattarov
In reply to this post by Igor Savlook
On 3/2/19 3:52 AM, Igor Savluk wrote:
>
>
> Можеш поставить dak там вообще postgresql.
я с aptly, потому что он умеет публиковать на амазоновский S3.
может ли это делать dak?
в принципе, залить файлы в хранилище много ума не нужно.

я сейчас пытаюсь вынести создание пакетов и публикацию их с Jenkins сервера с настроенным aptly на
GitlabCI.
в Gitlab всё происходит на уровне контейнеров, поэтому ни о какой базе которая бы мигрировала и
обновлялась вслед за каждым билдом речи быть не может
встаёт задача вынести базу куда то ещё, постгрес для этого в принципе подойдёт.
Насколько умён dak, чтобы уметь закинуть сгенерированный пакет в репу не имея под рукой ничего кроме
инструментов и эфемерного окружения
Ну и внешней базы конечно...

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Aleksandr Sytar
In reply to this post by Victor Wagner


сб, 2 мар. 2019 г. в 15:33, Victor Wagner <[hidden email]>:
В Sat, 2 Mar 2019 11:52:55 +0300
Igor Savluk <[hidden email]> пишет:


База данных - это не единственное средство организовать дурацкий поиск.
Вообще говоря, в deb-файле содержится более чем достаточно информации,
чтобы сгенерировать Packages file entry.


База данных, наверно едиственный способ сделать это предсказуемо быстро за ограниченное время. Сканирование deb-пакетов всегда будет иметь сложность не менее O(n). Поэтому в общем случае так никто не делает.
Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Andrey Jr. Melnikov
In reply to this post by Tim Sattarov
Tim Sattarov <[hidden email]> wrote:
> On 3/2/19 3:52 AM, Igor Savluk wrote:
> >
> >
> > Можеш поставить dak там вообще postgresql.
> я с aptly, потому что он умеет публиковать на амазоновский S3.
> может ли это делать dak?
> в принципе, залить файлы в хранилище много ума не нужно.
При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то
экзотику и работать с ней как с локальным диском - бесценно.
У меня reprepro свято уверен, что репозиторий на локальной машине.

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Eugene Berdnikov
On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:

> Tim Sattarov <[hidden email]> wrote:
> > On 3/2/19 3:52 AM, Igor Savluk wrote:
> > >
> > > Можеш поставить dak там вообще postgresql.
> > я с aptly, потому что он умеет публиковать на амазоновский S3.
> > может ли это делать dak?
> > в принципе, залить файлы в хранилище много ума не нужно.
> При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то
> экзотику и работать с ней как с локальным диском - бесценно.
> У меня reprepro свято уверен, что репозиторий на локальной машине.

 А у меня, к сожалению, нет уверенности в том, что при моргании сети,
 на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий.
 Потому как автор её скорее всего просто не предполагал, что репозиторий
 может быть удалённым, а дороги к нему будут перепаханы и минированы.

 Возможно, конкретно для reprepro проблемы нет, но в общем случае лучше
 делать репозиторий локальным, а с облаком синхронизовать после успешного
 завершения всех локальных транзакций, т.е. когда всё уже в файлах и в
 консистентном виде. Сохранить целостность при передаче в облако несложно,
 но это так лишь потому, что технология отработана -- авторы rsync/etc
 тщательно продумали все возможные сценарии сбоев, и мы этим пользуемся.
--
 Eugene Berdnikov

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Victor Wagner
In reply to this post by Aleksandr Sytar
В Sun, 3 Mar 2019 14:19:37 +0300
Aleksandr Sytar <[hidden email]> пишет:

> сб, 2 мар. 2019 г. в 15:33, Victor Wagner <[hidden email]>:
>
> > В Sat, 2 Mar 2019 11:52:55 +0300
> > Igor Savluk <[hidden email]> пишет:
> >
> >
> > База данных - это не единственное средство организовать дурацкий
> > поиск. Вообще говоря, в deb-файле содержится более чем достаточно
> > информации, чтобы сгенерировать Packages file entry.
> >
> >
> База данных, наверно едиственный способ сделать это предсказуемо
> быстро за ограниченное время. Сканирование deb-пакетов всегда будет
> иметь сложность не менее O(n). Поэтому в общем случае так никто не
> делает.

При разумно-реалистичных N зачастую выгоднее сделать n! но при
маленьком О, чем бороться за O(n) или O(log n) ценой увеличения O.

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

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

Но вот о чем совершенно не подумали авторы ни одной из рассмотренных
утилит, так это то, что Debian не единственный на свете дистрибутив.

Почему-то до сих пор мне попадались ровно два варианта:

Либо мы не обращаем внимания на существование в природе чего либо,
кроме нашего любимого дистрибутива, либо мы начинаем изобретать свой
собственный формат пакетов, что приводит к невозможности подтягивания
по зависимостям софта из пакетов, и самостоятельного пакетирования
perl, python, openssl et cetera et cetera.



--
                                   Victor Wagner <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Tim Sattarov
On 3/3/19 8:14 AM, Victor Wagner wrote:
>
> Но вот о чем совершенно не подумали авторы ни одной из рассмотренных
> утилит, так это то, что Debian не единственный на свете дистрибутив.
>
При таком запросе я боюсь что всё закончится чем то вроде fpm[1]
пол интернета этой фигнёй пакуют и радуются, что совместимы со всеми дистрибутивами


1: https://github.com/jordansissel/fpm/wiki

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Tim Sattarov
In reply to this post by Andrey Jr. Melnikov
On 3/3/19 6:31 AM, Andrey Jr. Melnikov wrote:

> Tim Sattarov <[hidden email]> wrote:
>> On 3/2/19 3:52 AM, Igor Savluk wrote:
>>>
>>> Можеш поставить dak там вообще postgresql.
>> я с aptly, потому что он умеет публиковать на амазоновский S3.
>> может ли это делать dak?
>> в принципе, залить файлы в хранилище много ума не нужно.
> При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то
> экзотику и работать с ней как с локальным диском - бесценно.
> У меня reprepro свято уверен, что репозиторий на локальной машине.
>
у S3 и файловых систем на нём основанных есть одна забавная особенность: не поддерживает файлов с
неизвестным заранее размером.
то есть  `cat >/mnt/s3fuse/file.txt` обломится
Потому что это не ФС, а объектное хранилище

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Stanislav Vlasov-2
04.03.2019, Tim Sattarov<[hidden email]> написал(а):

>> У меня reprepro свято уверен, что репозиторий на локальной машине.
>>
> у S3 и файловых систем на нём основанных есть одна забавная особенность: не
> поддерживает файлов с
> неизвестным заранее размером.
> то есть  `cat >/mnt/s3fuse/file.txt` обломится
> Потому что это не ФС, а объектное хранилище

Извращение тех времён, когда на работе пытались сделать своё S3-хранилище:
https://github.com/stanislavvv/stdin2s3

Вполне себе пишет файл на s3 c stdin и неизвестным размером.
Использовался ровно так, как написано в README.

Ну то есть объектное-то оно объектное, но докачку поддерживает.

--
Stanislav
Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Andrey Jr. Melnikov
In reply to this post by Eugene Berdnikov
Eugene Berdnikov <[hidden email]> wrote:

> On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:
> > Tim Sattarov <[hidden email]> wrote:
> > > On 3/2/19 3:52 AM, Igor Savluk wrote:
> > > >
> > > > Можеш поставить dak там вообще postgresql.
> > > я с aptly, потому что он умеет публиковать на амазоновский S3.
> > > может ли это делать dak?
> > > в принципе, залить файлы в хранилище много ума не нужно.
> > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то
> > экзотику и работать с ней как с локальным диском - бесценно.
> > У меня reprepro свято уверен, что репозиторий на локальной машине.

>  А у меня, к сожалению, нет уверенности в том, что при моргании сети,
>  на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий.
>  Потому как автор её скорее всего просто не предполагал, что репозиторий
>  может быть удалённым, а дороги к нему будут перепаханы и минированы.
Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто
привыкли, что типа "жосткий диск" он "рядом".

>  Возможно, конкретно для reprepro проблемы нет, но в общем случае лучше
>  делать репозиторий локальным, а с облаком синхронизовать после успешного
>  завершения всех локальных транзакций, т.е. когда всё уже в файлах и в
>  консистентном виде. Сохранить целостность при передаче в облако несложно,
>  но это так лишь потому, что технология отработана -- авторы rsync/etc
>  тщательно продумали все возможные сценарии сбоев, и мы этим пользуемся.
За дядин счет можно хоть в три места бакапы бакапить. Лично для меня
сдохший репозиторий с бинарными пакетами - неприятность, не стоящая того,
чтоб засирать место на дисках, оно там для других целей больше нужно.

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Victor Wagner
In reply to this post by Eugene Berdnikov
On Sun, 3 Mar 2019 15:32:47 +0300
Eugene Berdnikov <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Eugene Berdnikov
In reply to this post by Andrey Jr. Melnikov
On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <[hidden email]> wrote:
> > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:
...

> > > > в принципе, залить файлы в хранилище много ума не нужно.
> > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то
> > > экзотику и работать с ней как с локальным диском - бесценно.
> > > У меня reprepro свято уверен, что репозиторий на локальной машине.
>
> >  А у меня, к сожалению, нет уверенности в том, что при моргании сети,
> >  на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий.
> >  Потому как автор её скорее всего просто не предполагал, что репозиторий
> >  может быть удалённым, а дороги к нему будут перепаханы и минированы.
> Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто
> привыкли, что типа "жосткий диск" он "рядом".

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

 А написать работающий с файлами транзакционно выверенный софт это столь
 муторно, что получается лишь у профессионалов, занимающихся базами данных
 и кластерами. У остальных обычно не получается. Например, стоит положить
 файловую 1С с 5-15 юзерами на нестабильный канал, как через 2-3 месяца она
 разлетается вдрызг, а техподдержка 1С тихо сопит и советует перейти на
 трёхзвенку, т.е. архитектуру с транзакционным слоем снизу. Там и диски
 по отношению к слою приложения оказываются локальными, неудивительно,
 что на том же канале трёхзвенка 1С стабильно работает.
--
 Eugene Berdnikov

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Tim Sattarov
In reply to this post by Stanislav Vlasov-2
On 3/4/19 1:01 AM, Stanislav Vlasov wrote:

> 04.03.2019, Tim Sattarov<[hidden email]> написал(а):
>
>>> У меня reprepro свято уверен, что репозиторий на локальной машине.
>>>
>> у S3 и файловых систем на нём основанных есть одна забавная особенность: не
>> поддерживает файлов с
>> неизвестным заранее размером.
>> то есть  `cat >/mnt/s3fuse/file.txt` обломится
>> Потому что это не ФС, а объектное хранилище
> Извращение тех времён, когда на работе пытались сделать своё S3-хранилище:
> https://github.com/stanislavvv/stdin2s3
>
> Вполне себе пишет файл на s3 c stdin и неизвестным размером.
> Использовался ровно так, как написано в README.
>
> Ну то есть объектное-то оно объектное, но докачку поддерживает.
>
О, прикольно, гляну.
Спасибо :)

Reply | Threaded
Open this post in threaded view
|

Re: Генерация pool-based репозиториев

Artem Chuprina-4
In reply to this post by Victor Wagner
Victor Wagner -> [hidden email]  @ Mon, 4 Mar 2019 17:28:51 +0300:

 > Чтобы миррор всегда был консистентным, необходимо действовать в
 > следующей последовательности:

 > 1. Сначала скачать все новые пакеты
 > 2. Потом скопировать Packages{,.gz,.bz2} Release и Release.gpg и
 > единомоментно атоммарной операцией из заменить.
 > 3. Удалить более ненужные пакеты.

 > А rsync --delete делает не так. Он СНАЧАЛА удаляет более ненужные
 > файлы, а потом уже копирует новые.

rsync --delete-after

и вообще почитать, какие там бывают варианты у delete.

 > Ну и о том, что Release содержит контрольную сумму Packages и менять
 > их нужно одновременно - тоже не в курсе.

А вот этого он уже не знает, конечно.

Есть еще чуть более хитрый вариант — cp -al, rsync в копию, и потом
_почти_ атомарная пара rename либо перевешивание симлинка (тоже _почти_
атомарное). Второе лучше (см. ниже).

 > Отдельное развлечение случается когда у тебя параллельно работает
 > десяток jenkins-овских заданий, собирающих разные пакеты, зависящие
 > друг от друга. Может запросто получиться так, что задание 1 сделало
 > apt-get update, потом задание 2 выложило новую версию своего пакета
 > и перергенерировало packages, а потом задание 1 захотело этот пакет
 > поставить, потому что он у него Build-Depends.

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

То, что задание 2 перегенерировало packages, само по себе для задания 1,
которое уже сделало apt-get update, по барабану. Важно, чтобы пакет
оставался.

Другое дело, что race condition вида "у задания 1 прямо в процессе
apt-get update могли оказаться Release и Packages разных версий
репозитория" все равно остается.

Чтобы его не было, см. выше про симлинк. Перед apt-get update делается
readlink, прочитанное имя пишется в sources.list, и уже с этим
отрезолвленным именем, где заведомо консистентный репозиторий, который
уже никогда не поменяется, можно работать.

 > Прикрутить туда осмысленную систему exclusive и shared блокировок при
 > условии того, что задания крутятся на куче разных машин и в репозиторий
 > ходят apt-ом весьма нетривиально.

Любая система с блокировками содержит race condition :) Один мутекс еще
нет, а любая система уже да.

12