[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



В Sun, 3 Mar 2019 14:19:37 +0300
Aleksandr Sytar <sytar.alex@gmail.com> пишет:

> сб, 2 мар. 2019 г. в 15:33, Victor Wagner <vitus@wagner.pp.ru>:
> 
> > В Sat, 2 Mar 2019 11:52:55 +0300
> > Igor Savluk <isav@alzari.pw> пишет:
> >
> >
> > База данных - это не единственное средство организовать дурацкий
> > поиск. Вообще говоря, в 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 <vitus@wagner.pp.ru>


Reply to: