[devel] changelogs for apt repo

[Alexey Tourbin]

On Sun, May 18, 2008 at 01:58:11AM +0400, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> >Но там уже есть description (а не только summary).  
> >Так что для чего
> >предназначен pkglist это вопрос 
> >неоднозначный.
> 
> Эта информация нужна для поиска.

Значит, предназначение pkglist двоякое: как текстовая информация
для чтения человеком (и поиска), так и информация для установки
пакетов и автоматического разрешения зависимостей.

> >Какая плата тебя бы устроила?  Думаю что 
> >плату можно будет немного
> >уменьшить, если сначала отсортировать 
> >пакеты по %{SOURCERPM}, а уже
> >потом выгонять хедеры.  Тогда bzip2 лучше 
> >сожмёт одинаковые changelog'и
> >подряд идущих подпакетов.
> 
> Может пойти по другому пути и разбить 
> этот файл. Чтобы трафик между сервером и 
> обновляемым клиентом была меньше. Ведь, 
> как ты правильно сказал, pkglist это 
> сваленные в одну кучу хэдеры (плюс они 
> ещё пожаты). Если переделать алгоритм 
> чтобы хэдеры передавались по одиночке, а 
> на стороне клиента объединялись, то 
> скачиваться будут только новые и 
> изменённые хэдеры.

Если класть хедеры в отдельные файлы, то оверхед в связи с этим
будет очень большой (это и inode'ы, и перекачка информации о файлах).
На самом деле если pkglist не сжимать, то rsync прокачает его гораздо
быстрее (особенно если отсортировать хедеры по %{SOURCERPM}).  Средний
размер хедера в pkglist 2K, если сделать rsync --block-size=1K то мы
возьмём почти чистый diff (с оверхедом того же порядка, что и при
передаче хедеров по отдельности).  Но почему-то почти все используют
ftp, и ради них pkglist бзипют.

> Сейчас меня несколько волнует, что при 
> обновлении к тебе на машину копируются 
> хэдеры от *всех* пакетов в сизифе вне 
> зависимости изменились они или нет.

Это всё-таки не очень большой объем информации (3-4M) по сравнению
с типичным размером dist-upgrade.

> >И это будет опция.  Если ты генерируешь 
> >свой репозитарий с жесткими
> >ограничениями на размер, то это можно 
> >бдует отключить.
> 
> Но сизиф-то будет с этой информацией. И 
> поэтому у всех наших клиентов ты 
> увеличишь размер pkglist.

А также все клиенты смогут читать changelog'и ДО того, как что-то
скачать и обновить (хуже того, apt устроен таким образом, что даже в
промежуток между скачать и обновить довольно-таки неудобно вклиниться --
можно, конечно, сделать apt-get --download-only и потом искать скоченые
*.rpm'ы в /var/*/apt, которые он к тому же манглит...).

В общем, взыскательные клиенты могут и оценить фичу.

> >Есть такая дилемма.
> 
> Так может написать такую поддержку в apt и 
> перейти на них. В этих базах есть всё что 
> может понадобиться. Это тоже хэдеры плюс 
> индексы.

apt всё равно создаёт свой собственный pkgcache.bin, который он mmap'ит
в память, и все его алгоритмы завязаны на формат этого кеша (который я
плохо понимаю!).

И, собственно, rpmdb как альтернатива pkglist ничего не экономит;
а rpmdb как дополнение к pkglist порождает вопросы, напр. должна ли
эта rpmdb скачиваться при apt-get update или нет.  Или у неё статус
такой же как у contents_index.  Типа кто-то его туда наклал.

> >Но ведь мы можем обновляться не с 
> >предпоследней версии на последнюю,
> >а с ещё более ранней.  То есть мы можем 
> >пропустить промежуточное важное
> >изменение.  Поэтому есть наибольший 
> >смысл сохранять changelog'и строго
> >по известной дате, как я и предлагаю 
> >сделать.
> 
> И за сколько будем хранить, за год? Через 
> какой период по вашему люди обновляются 
> сидя на сизифе (ведь именно этот период 
> тебе и нужно охватить с таким подходом) ?

Ну, сейчас "эпоха" начинается с бранча 4.0.  Видимо за три года где-то.
Но по идее за эти ближайшие годы инфраструктура интернета разовьётся не
меньше, чем мы успеем написать changelog'ов.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080518/24c7b4e5/attachment-0002.bin>