Re: Генерация pool-based репозиториев
04.03.2019, Tim Sattarov написал(а): >> У меня reprepro свято уверен, что репозиторий на локальной машине. >> > у S3 и файловых систем на нём основанных есть одна забавная особенность: не > поддерживает файлов с > неизвестным заранее размером. > то есть `cat >/mnt/s3fuse/file.txt` обломится > Потому что это не ФС, а объектное хранилище Извращение тех времён, когда на работе пытались сделать своё S3-хранилище: https://github.com/stanislavvv/stdin2s3 Вполне себе пишет файл на s3 c stdin и неизвестным размером. Использовался ровно так, как написано в README. Ну то есть объектное-то оно объектное, но докачку поддерживает. -- Stanislav
Re: Генерация pool-based репозиториев
On 3/3/19 6:31 AM, Andrey Jr. Melnikov wrote: > Tim Sattarov 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` обломится Потому что это не ФС, а объектное хранилище
Re: Генерация pool-based репозиториев
On 3/3/19 8:14 AM, Victor Wagner wrote: > > Но вот о чем совершенно не подумали авторы ни одной из рассмотренных > утилит, так это то, что Debian не единственный на свете дистрибутив. > При таком запросе я боюсь что всё закончится чем то вроде fpm[1] пол интернета этой фигнёй пакуют и радуются, что совместимы со всеми дистрибутивами 1: https://github.com/jordansissel/fpm/wiki
Re: Генерация pool-based репозиториев
В Sun, 3 Mar 2019 14:19:37 +0300 Aleksandr Sytar пишет: > сб, 2 мар. 2019 г. в 15:33, Victor Wagner : > > > В Sat, 2 Mar 2019 11:52:55 +0300 > > Igor Savluk пишет: > > > > > > База данных - это не единственное средство организовать дурацкий > > поиск. Вообще говоря, в 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
Re: Генерация pool-based репозиториев
On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > Tim Sattarov 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
Re: Генерация pool-based репозиториев
Tim Sattarov wrote: > On 3/2/19 3:52 AM, Igor Savluk wrote: > > > > > > Можеш поставить dak там вообще postgresql. > я с aptly, потому что он умеет публиковать на амазоновский S3. > может ли это делать dak? > в принципе, залить файлы в хранилище много ума не нужно. При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то экзотику и работать с ней как с локальным диском - бесценно. У меня reprepro свято уверен, что репозиторий на локальной машине.
Re: Генерация pool-based репозиториев
сб, 2 мар. 2019 г. в 15:33, Victor Wagner : > В Sat, 2 Mar 2019 11:52:55 +0300 > Igor Savluk пишет: > > > База данных - это не единственное средство организовать дурацкий поиск. > Вообще говоря, в deb-файле содержится более чем достаточно информации, > чтобы сгенерировать Packages file entry. > > База данных, наверно едиственный способ сделать это предсказуемо быстро за ограниченное время. Сканирование deb-пакетов всегда будет иметь сложность не менее O(n). Поэтому в общем случае так никто не делает.
