Re: Генерация pool-based репозиториев
Eugene Berdnikov <bd4@protva.ru> wrote:
> On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:
> > Tim Sattarov <stimur@gmail.com> 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 to: