[devel] changelogs for apt repo

[devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 5348 bytes --]

Я реализовал включение changelog'ов пакетов в репозитарий и показ их
в 'apt-cache show' (см. мой apt.git).  Работать должно примерно вот так:

$ ./aptbox/apt-cache show perl-YAML |обрезать_домен_мыла
Package: perl-YAML
Section: Development/Perl
Installed Size: 142319
Maintainer: Alexey Tourbin <at@altlinux>
Version: 0.66-alt1
Build Date: Sat May 17 08:52:46 2008
Pre-Depends: rpmlib(PayloadFilesHavePrefix) (<= 4.0-1), rpmlib(CompressedFileNames) (<= 3.0.4-1), rpmlib(VersionedDependencies) (<= 3.0.3-1)
Depends: /usr/bin/perl, perl(Data/Dumper.pm), perl(Term/ReadLine.pm), perl(base.pm), perl(constant.pm), perl(overload.pm), perl(warnings.pm), perl-base (>= 1:5.6.1)
Provides: perl(YAML.pm) (= 0.660), perl(YAML/Base.pm), perl(YAML/Dumper.pm), perl(YAML/Dumper/Base.pm), perl(YAML/Error.pm), perl(YAML/Loader.pm), perl(YAML/Loader/Base.pm), perl(YAML/Marshall.pm), perl(YAML/Node.pm), perl(YAML/Tag.pm), perl(YAML/Types.pm), perl-YAML (= 0.66-alt1)
Architecture: noarch
Size: 48657
MD5Sum: 14f76d223da25a4036a8f771c67bb518
Filename: perl-YAML-0.66-alt1.noarch.rpm
Description: YAML Ain't Markup Language
 The YAML.pm module implements a YAML Loader and Dumper based on the
 YAML 1.0 specification.  YAML is a generic data serialization language
 that is optimized for human readability.  It can be used to express the
 data structures of most modern programming languages (including Perl).
Changelog:
 * Sat May 17 2008 Alexey Tourbin <at@altlinux> 0.66-alt1
 - 0.65 -> 0.66
 * Sat Aug 18 2007 Alexey Tourbin <at@altlinux> 0.65-alt1
 - 0.62 -> 0.65
 * Wed Dec 20 2006 Alexey Tourbin <at@altlinux> 0.62-alt1
 - 0.60 -> 0.62
 - fixed dependency on B::Deparse (cpan #24018)

Package: perl-YAML
Section: Development/Perl
Installed Size: 142138
Maintainer: Alexey Tourbin <at@altlinux>
Version: 0.65-alt1
Pre-Depends: rpmlib(PayloadFilesHavePrefix) (<= 4.0-1), rpmlib(CompressedFileNames) (<= 3.0.4-1), rpmlib(VersionedDependencies) (<= 3.0.3-1)
Depends: perl(Data/Dumper.pm), perl(Term/ReadLine.pm), perl(base.pm), perl(constant.pm), perl(overload.pm), perl(warnings.pm), perl-base (>= 1:5.6.1)
Provides: perl(YAML.pm) (= 0.650), perl(YAML/Base.pm), perl(YAML/Dumper.pm), perl(YAML/Dumper/Base.pm), perl(YAML/Error.pm), perl(YAML/Loader.pm), perl(YAML/Loader/Base.pm), perl(YAML/Marshall.pm), perl(YAML/Node.pm), perl(YAML/Tag.pm), perl(YAML/Types.pm), perl-YAML (= 0.65-alt1)
Architecture: noarch
Size: 48585
MD5Sum: 5c51993475a98083561540d9c5ea4a68
Filename: perl-YAML-0.65-alt1.noarch.rpm
Description: YAML Ain't Markup Language
 The YAML.pm module implements a YAML Loader and Dumper based on the
 YAML 1.0 specification.  YAML is a generic data serialization language
 that is optimized for human readability.  It can be used to express the
 data structures of most modern programming languages (including Perl).

$ 

Здесь 'apt-cache show' показывает два пакета (отличаются версии).
Первый пакет, который я только что собрал -- из моего локального
репозитария.  Этот репозитарий был сгенерирован с включением
changelog'ов, и поэтому 'apt-cache show' показывает changelog.
Второй пакет -- из Сизифа, который сгенерирован без changelog'ов.

Теперь встает вопрос, сколько штук changelog entries копировать при
генерации репозитария, если не все.  Я сначала сделал несколько опций
управления количеством штук, но в конце решил оставить всего одну:

   --changelog-since=DATE     Save package changelogs; copy changelog entries
                              only newer than DATE, and also one entry before
                              the DATE (if available)

Поясню работу этой опции при помощи рисунка:

                 +    +          +    +
------------------|------------------------> t
  *    * *    *  DATE

Здесь на шкале времени плюсами отмечены changelog entries, которые
копируются в файл base/pkglist.*, а звёздочками -- которые не копируются.
То есть, при такой схеме мы знаем последнюю запись в changelog'е пакета
по состоянию на час X, от которого мы отсчитываем, а также все
последующие записи.  Кроме того, копируется как минимум одна запись,
так что команде 'apt-cache show' всегда есть что показать.

Кандидаты на час X следующие:
1) 2007-01-01 -- интуитивно понятная дата;
2) 2007-04-?? -- когда отфоркался branch 4.0.

Теперь остаётся выяснить, сколько это занимает места.

Обычная генерация сизифа:

$ cp -prs /ALT/Sisyphus/x86_64 /ALT/Sisyphus/noarch .
$ rm -f x86_64/base/* noarch/base/*
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD x86_64
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD noarch
$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2 
2421    x86_64/base/pkglist.classic.bz2
1049    noarch/base/pkglist.classic.bz2
$ 

Генерация с опцией --changelog-since=2007-01-01:

$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 x86_64
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 noarch
$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
3536    x86_64/base/pkglist.classic.bz2
1302    noarch/base/pkglist.classic.bz2
$ 

Таким образом, размер скачиваемого при 'apt-get update' заметно
увеличивается (примерно на треть).  Я считаю это приемлемой платой
за удовольствие просмотреть changelog пакета ДО скачивания и установки.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Евгений Терешков]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

<#secure method=pgp mode=sign>
Alexey Tourbin пишет:

> Я реализовал включение changelog'ов пакетов в репозитарий и показ их
> в 'apt-cache show' (см. мой apt.git).  Работать должно примерно вот так:

(наглядные объяснения поскипаны)

Я одного не понял: если есть несколько версий (2, 3, 5, 10) одного пакета
из двух (и более) репозиториев, созданных с включением в них changelog'ов,
то apt-cache show <pkgname> покажет один лог для какой-то (например, самой
свежей) версий или все для всех версий (или как-то иначе?)?

И ещё: возможно, имеет смысл сделать включаемым весь changelog (разумеется,
с каким-то разумным лимитом по объёму)? Тогда в вывод попадут записи об
изменениях пакетов из разряда "залил и забыл, just works", которые в
противном случае потерялись бы.

P.S.: не делал выборку по таким пакетам, просто первая пришедшая мысль.

-- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 x86_64
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 noarch
> $ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
> 3536    x86_64/base/pkglist.classic.bz2
> 1302    noarch/base/pkglist.classic.bz2
> $ 
> 
> Таким образом, размер скачиваемого при 'apt-get update' заметно
> увеличивается (примерно на треть).  

Это ужасно.Для меня это слишком дорогая плата. Мне кажется что pkglist 
был придуман не для того как ты его используешь.

Ты идёшь по пути перекачивания на пользовательскую машину
sisyphus/<arch>/rpmdb ... может уже так и сделать ?

> Я считаю это приемлемой платой
> за удовольствие просмотреть changelog пакета ДО скачивания и установки.

Может имеет смысл добавлять lastchange? Ведь интересно видеть что 
изменилось в последней версии чтобы понять ставить её или нет, а не в 
какой-то предыдущей.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Sat, May 17, 2008 at 04:06:09PM +0400, Alexey Gladkov wrote:
> Это ужасно.Для меня это слишком дорогая плата. Мне кажется что pkglist был 
> придуман не для того как ты его используешь.
+1

> Может имеет смысл добавлять lastchange? Ведь интересно видеть что 
> изменилось в последней версии чтобы понять ставить её или нет, а не в 
> какой-то предыдущей.
Это если постоянно обновляться.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Не надо заходить как root на 5 runlevel'е. Вы же не хотите чтобы Вам
снесло систему, например, после просмотра konqueror'ом некоторого сайта ;)
		-- inger in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> Это если постоянно обновляться.

Если хранить весь changelog то pkglist будет увеличиваться в размере 
причём постоянно и независимо от количества пакетов. При этом 
*большая* часть информации будет не нужна.

Если хранить не всё, то нужно придумывать сколько времени отслеживать 
(как и сказал Алексей).

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

On Sat, May 17, 2008 at 04:06:09PM +0400, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> >$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 
> >x86_64
> >$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 
> >noarch
> >$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
> >3536    x86_64/base/pkglist.classic.bz2
> >1302    noarch/base/pkglist.classic.bz2
> >$ 
> >
> >Таким образом, размер скачиваемого при 
> >'apt-get update' заметно
> >увеличивается (примерно на треть).  
> 
> Это ужасно.Для меня это слишком дорогая 
> плата. Мне кажется что pkglist был придуман 
> не для того как ты его используешь.

Но там уже есть description (а не только summary).  Так что для чего
предназначен pkglist это вопрос неоднозначный.  В pkglist вообще-то
просто копируются хедеры (и их можно читать прямо в цикле через
headerRead), но при копировании хедеры основательно урезаются,
исключительно с целью экономии места.

На самом деле то что через apt нельзя посмотреть изменения в пакете
это одна из основных претензий к апту.  Александр Боковой ещё
в х**-знает-каком году писал, как он в Сане показывал наш synaptic, 
и первое что у него саны спросили это где посмотреть изменения
обновляемых пакетов.

Какая плата тебя бы устроила?  Думаю что плату можно будет немного
уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
подряд идущих подпакетов.

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

> Ты идёшь по пути перекачивания на 
> пользовательскую машину
> sisyphus/<arch>/rpmdb ... может уже так и сделать ?

Есть такая дилемма.

> >Я считаю это приемлемой платой
> >за удовольствие просмотреть changelog 
> >пакета ДО скачивания и установки.
> 
> Может имеет смысл добавлять lastchange? Ведь 
> интересно видеть что изменилось в 
> последней версии чтобы понять ставить её 
> или нет, а не в какой-то предыдущей.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Led]

Saturday, 17 May 2008 22:00:34 Alexey Tourbin написав:
> > Это ужасно.Для меня это слишком дорогая
> > плата. Мне кажется что pkglist был придуман
> > не для того как ты его используешь.
>
> Но там уже есть description (а не только summary).

А что, кого-то спрашивали, нужен ли там description? ИМХО не нужен и он.

-- 
Led

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Sat, May 17, 2008 at 11:01:08PM +0300, Led wrote:
> А что, кого-то спрашивали, нужен ли там description? ИМХО не нужен и он.
А как выяснять, тот ли это пакет, что нужен?
Плюсм apt-cache search особого смысла не имеет без дескрипшенов.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<Ktirf> wRAR: Вот ты что сделал, чтобы на UTF-8 перейти?
<wRAR> Ktirf: .i18n поправил. а что?
<combr> wRAR: нет, а глобально? в плане общественной жизни? ;))

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Led]

Saturday, 17 May 2008 22:55:45 Andrey Rahmatullin написав:
> On Sat, May 17, 2008 at 11:01:08PM +0300, Led wrote:
> > А что, кого-то спрашивали, нужен ли там description? ИМХО не нужен и он.
>
> А как выяснять, тот ли это пакет, что нужен?

Вменяемый Summary - достаточно.

> Плюсм apt-cache search особого смысла не имеет без дескрипшенов.

См. выше. Но яопять же - это ИМХО.

-- 
Led

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Sun, May 18, 2008 at 12:16:21AM +0300, Led wrote:
> Вменяемый Summary - достаточно.
Наивно enough.

> > Плюсм apt-cache search особого смысла не имеет без дескрипшенов.
> См. выше. Но яопять же - это ИМХО.
А это просто бред.
См. многочисленные техники прописывания всякой полезной инфы в дескрипшен
именно с целью релевантного apt-cache search.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> На самом деле реально нужен хороший и безглючный биллинг ;)
> Легко настраиваемый, удобный и функциональный.
И бесплатным сертификатом госсвязи ;)
		-- lakostis in sysadmins@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Kirill Maslinsky]

On Sun, May 18, 2008 at 03:09:39AM +0600, Andrey Rahmatullin wrote:
> On Sun, May 18, 2008 at 12:16:21AM +0300, Led wrote:
> > Вменяемый Summary - достаточно.
> Наивно enough.
> 
> > > Плюсм apt-cache search особого смысла не имеет без дескрипшенов.
> > См. выше. Но яопять же - это ИМХО.
> А это просто бред.
> См. многочисленные техники прописывания всякой полезной инфы в дескрипшен
> именно с целью релевантного apt-cache search.
Кстати, тоже неплохо бы оформить в полиси (хотя бы даже HOWTO),
как писать description и summary. А то они не всегда бывают 
информативные.


--
Kirill Maslinsky
ALT Linux Team

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Sat, May 17, 2008 at 11:01:08PM +0300, Led wrote:
> Saturday, 17 May 2008 22:00:34 Alexey Tourbin написав:
> > > Это ужасно.Для меня это слишком дорогая
> > > плата. Мне кажется что pkglist был придуман
> > > не для того как ты его используешь.
> >
> > Но там уже есть description (а не только summary).
> 
> А что, кого-то спрашивали, нужен ли там description? ИМХО не нужен и он.

Для apt-cache search нужен.  Кстати, если в поиск включить changelog'и,
то можно будет искать apt-cache search CVE и т.п.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> Но там уже есть description (а не только summary).  Так что для чего
> предназначен pkglist это вопрос неоднозначный.

Эта информация нужна для поиска.

> В pkglist вообще-то
> просто копируются хедеры (и их можно читать прямо в цикле через
> headerRead), но при копировании хедеры основательно урезаются,
> исключительно с целью экономии места.

Это я знаю :)
Вот именно. Их урезают и делают как можно меньше чтобы не перегружать 
пользовательскую машину информацией о всём репозитории.

> Какая плата тебя бы устроила?  Думаю что плату можно будет немного
> уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
> потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
> подряд идущих подпакетов.

Может пойти по другому пути и разбить этот файл. Чтобы трафик между 
сервером и обновляемым клиентом была меньше. Ведь, как ты правильно 
сказал, pkglist это сваленные в одну кучу хэдеры (плюс они ещё 
пожаты). Если переделать алгоритм чтобы хэдеры передавались по 
одиночке, а на стороне клиента объединялись, то скачиваться будут 
только новые и изменённые хэдеры.

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

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

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

> Есть такая дилемма.

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

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

И за сколько будем хранить, за год? Через какой период по вашему люди 
обновляются сидя на сизифе (ведь именно этот период тебе и нужно 
охватить с таким подходом) ?

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On Sun, May 18, 2008 at 01:58:11AM +0400, Alexey Gladkov wrote:
> Может пойти по другому пути и разбить этот файл. Чтобы трафик между 
> сервером и обновляемым клиентом была меньше.
В дебиане давно уже диффы пересылаются, привет.


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

А не то что correctly - не correctly.
		-- wrar in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> В дебиане давно уже диффы пересылаются, привет.

Очень за них рад, но у нас нет диффов, привет.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Sun, May 18, 2008 at 02:14:34AM +0400, Alexey Gladkov wrote:
>> В дебиане давно уже диффы пересылаются, привет.
> Очень за них рад, но у нас нет диффов, привет.
Ну так может в этом направлении и думать?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> >огласить весь список rpm -qa | grep ^kde? :)
> >3.2.3, Sisyphus (20040804)
> Ничче не понимаю. У меня вроде то же самое (см. выше). Будем Зерга звать?
пора.

Зееерггггг!!!!!?
		-- shrek in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> Ну так может в этом направлении и думать?

Разумеется. С ростом репозитория служебной информации будет всё 
больше. Плюс Алексей способствует её увеличению :)

Хотите попробовать прикрутить поддержку диффов?

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On Sun, May 18, 2008 at 02:21:39AM +0400, Alexey Gladkov wrote:
> Хотите попробовать прикрутить поддержку диффов?
Ох.
Почему-то кажется, что не хочу.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> kak otpisatsa ot etoi rassulki? =)
Отписка происходит автоматически по итогам месяца.
		-- lav in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> Ох.
> Почему-то кажется, что не хочу.

Вот именно потому что все так отвечают у нас нет диффов в apt.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > Alexey Tourbin wrote:
 >> Но там уже есть description (а не только summary).  Так что для чего
 >> предназначен pkglist это вопрос неоднозначный.

 > Эта информация нужна для поиска.

 >> В pkglist вообще-то
 >> просто копируются хедеры (и их можно читать прямо в цикле через
 >> headerRead), но при копировании хедеры основательно урезаются,
 >> исключительно с целью экономии места.

 > Это я знаю :)
 > Вот именно. Их урезают и делают как можно меньше чтобы не перегружать
 > пользовательскую машину информацией о всём репозитории.

 >> Какая плата тебя бы устроила?  Думаю что плату можно будет немного
 >> уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
 >> потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
 >> подряд идущих подпакетов.

 > Может пойти по другому пути и разбить этот файл. Чтобы трафик между
 > сервером и обновляемым клиентом была меньше. Ведь, как ты правильно
 > сказал, pkglist это сваленные в одну кучу хэдеры (плюс они ещё
 > пожаты). Если переделать алгоритм чтобы хэдеры передавались по
 > одиночке, а на стороне клиента объединялись, то скачиваться будут
 > только новые и изменённые хэдеры.

Либо разбить на два:
первый -- старый минус дескрипшны, второй -- дополнительный,
с дескрипшнами и полным чейнджлогом.
Качать ли второй -- скажем, опцией в apt.conf.

-- 

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3858 bytes --]

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'ов.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Ildar Mulyukov]

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

	Алексей,

поделитесь, пожалуйста, как настроить apt, чтобы это делать? Или Вы  
имеете в виду напрямую rsync-ом?

С уважением,
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

On Mon, May 19, 2008 at 10:02:03AM +0600, Ildar Mulyukov wrote:
> On 18.05.2008 05:03:31, Alexey Tourbin wrote:
> >Если класть хедеры в отдельные файлы, то 
> >оверхед в связи с этим будет  очень 
> >большой (это и inode'ы, и перекачка 
> >информации о файлах). На  самом деле если 
> >pkglist не сжимать, то rsync прокачает его 
> >гораздо  быстрее (особенно если 
> >отсортировать хедеры по %{SOURCERPM}).   
> >Средний размер хедера в pkglist 2K, если 
> >сделать rsync  --block-size=1K то мы возьмём почти 
> >чистый diff (с оверхедом того же  порядка, 
> >что и при передаче хедеров по 
> >отдельности).  Но почему-то  почти все 
> >используют ftp, и ради них pkglist бзипют.
> 
> 	Алексей,
> 
> поделитесь, пожалуйста, как настроить apt, 
> чтобы это делать? Или Вы  имеете в виду 
> напрямую rsync-ом?

Дело в том, что rsync(1) как раз очень хорошо подохдит для
синхронизации бинарных (и вообще любых) файлов, в которых некоторые
куски меняются (возможно, со смещением), а некоторые куски остаются
без изменения (возможно, тоже со смещением).  Почитайте где-нибудь
статью этого гуру я не помню как его на букву T тоже.  Там очень
хорошо описано, как файл разбивается на маленькие блоки, и на стороне
клиента вычисляются всевозможные хеши для любых смещений.

Поняв это, Вам также станят ясно (как Божий день), что совсем не нужен
ещё один протокол для синхронизации кусков чего-то с другими кусками
ещё чего-то.  Достаточно одного хорошего протокола, коим является rsync.

Проблема только в том, что rsync "не берёт" сжатые файлы.  Это связано
с понятием об этнропии, и это очень долго объяснять.  Суть в том что
сжатие полностью уничтожает буквально совпадение блоков, которое нужно
для rsync.  

В общем, дилемма простая: либо синхронизируем разжатое, либо полностью
скачиваем сжатое.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Ildar Mulyukov]

On 19.05.2008 10:53:14, Alexey Tourbin wrote:
> On Mon, May 19, 2008 at 10:02:03AM +0600, Ildar Mulyukov wrote:
> > On 18.05.2008 05:03:31, Alexey Tourbin wrote:
>>> Если класть хедеры в отдельные файлы, то оверхед в связи с этим  
>>> будет  очень большой (это и inode'ы, и перекачка информации о  
>>> файлах). На  самом деле если pkglist не сжимать, то rsync прокачает  
>>> его гораздо  быстрее (особенно если отсортировать хедеры по  
>>> %{SOURCERPM}). Средний размер хедера в pkglist 2K, если сделать  
>>> rsync  --block-size=1K то мы возьмём почти чистый diff (с оверхедом  
>>> того же  порядка, что и при передаче хедеров по отдельности).  Но  
>>> почему-то  почти все используют ftp, и ради них pkglist бзипют.
>> 	Алексей, поделитесь, пожалуйста, как настроить apt, чтобы это  
>> делать? Или Вы  имеете в виду напрямую rsync-ом?
> 
> Дело в том, что rsync(1) как раз очень хорошо подохдит для  
> синхронизации бинарных (и вообще любых) файлов, в которых некоторые  
> куски меняются (возможно, со смещением), а некоторые куски остаются  
> без изменения (возможно, тоже со смещением).  Почитайте где-нибудь  
> статью этого гуру я не помню как его на букву T тоже.  Там очень  
> хорошо описано, как файл разбивается на маленькие блоки, и на стороне  
> клиента вычисляются всевозможные хеши для любых смещений.
> Поняв это, Вам также станят ясно (как Божий день), что совсем не  
> нужен ещё один протокол для синхронизации кусков чего-то с другими  
> кусками ещё чего-то.  Достаточно одного хорошего протокола, коим  
> является rsync.


А! Спасибо. Как работает rsync - я уже немного в курсе.

> Проблема только в том, что rsync "не берёт" сжатые файлы.  Это  
> связано с понятием об этнропии, и это очень долго объяснять.  Суть в  
> том что сжатие полностью уничтожает буквально совпадение блоков,  
> которое нужно для rsync.
> В общем, дилемма простая: либо синхронизируем разжатое, либо полностью
> скачиваем сжатое.

Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.

Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

On Mon, May 19, 2008 at 04:26:02PM +0600, Ildar Mulyukov wrote:
> Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.
apt-get install apt-rsync
Не знаю, правда, как он работает.

Re: [devel] changelogs for apt repo

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Mon, May 19, 2008 at 10:35:46AM +0000, Andrey Rahmatullin wrote:
> On Mon, May 19, 2008 at 04:26:02PM +0600, Ildar Mulyukov wrote:
> > Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.
> apt-get install apt-rsync
> Не знаю, правда, как он работает.

Нормально работает, rsync -- один из apt methods становится.

-- 
[...] любители ругаться не читают документацию :-)
		-- aen in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

On Mon, May 19, 2008 at 02:41:07PM +0400, Pavlov Konstantin wrote:
> Нормально работает, rsync -- один из apt methods становится.
Знаю, даже юзал. Я про экономию и прочее.

Re: [devel] changelogs for apt repo

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Pavlov Konstantin пишет:
> On Mon, May 19, 2008 at 10:35:46AM +0000, Andrey Rahmatullin wrote:
>> On Mon, May 19, 2008 at 04:26:02PM +0600, Ildar Mulyukov wrote:
>>> Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.
>> apt-get install apt-rsync
>> Не знаю, правда, как он работает.
> 
> Нормально работает, rsync -- один из apt methods становится.

  Не совсем нормально: по apt-get update каждый раз _полностью_
выкачивает файлы описания репозитария, даже если они не менялись. (Для
ftp -- это не так.)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [devel] changelogs for apt repo

[Alexander Bokovoy]

19.05.08, Alexey Tourbin<at@altlinux.ru> написал(а):
>  Проблема только в том, что rsync "не берёт" сжатые файлы.  Это связано
>  с понятием об этнропии, и это очень долго объяснять.  Суть в том что
>  сжатие полностью уничтожает буквально совпадение блоков, которое нужно
>  для rsync.
На самом деле, если жать gzip --rsyncable, то будут блоки по 100к, что
как раз и помогает rsync. В случае bzip2 блоки будут 900к (--best или
по умолчанию) или кратны 100к (-1, -2 и так далее -- это 100к, 200к,
... до 900к с -9). То есть, если для rsync указать размер блока в
размер блока, с которым сжимались данные при помощи bzip2, то
производительность будет выше, чем без понимания размера блока.


-- 
/ Alexander Bokovoy

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 12785 bytes --]

On Sat, May 17, 2008 at 09:34:27AM +0400, Alexey Tourbin wrote:
> Теперь остаётся выяснить, сколько это занимает места.
> 
> Обычная генерация сизифа:
> 
> $ cp -prs /ALT/Sisyphus/x86_64 /ALT/Sisyphus/noarch .
> $ rm -f x86_64/base/* noarch/base/*
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD x86_64
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD noarch
> $ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2 
> 2421    x86_64/base/pkglist.classic.bz2
> 1049    noarch/base/pkglist.classic.bz2
> $ 
> 
> Генерация с опцией --changelog-since=2007-01-01:
> 
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 x86_64
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 noarch
> $ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
> 3536    x86_64/base/pkglist.classic.bz2
> 1302    noarch/base/pkglist.classic.bz2
> $ 
> 
> Таким образом, размер скачиваемого при 'apt-get update' заметно
> увеличивается (примерно на треть).  Я считаю это приемлемой платой
> за удовольствие просмотреть changelog пакета ДО скачивания и установки.

On Sat, May 17, 2008 at 11:00:34PM +0400, Alexey Tourbin wrote:
> Какая плата тебя бы устроила?  Думаю что плату можно будет немного
> уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
> потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
> подряд идущих подпакетов.

Я сделал предварительную реализацию сортировки по %{SOURCERPM}.
Результаты теперь такие:

$ PATH=$PWD:$PATH genbasedir --topdir=$PWD x86_64
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD noarch
$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
2384    x86_64/base/pkglist.classic.bz2
1048    noarch/base/pkglist.classic.bz2
$

$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 x86_64
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 noarch
$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
3306    x86_64/base/pkglist.classic.bz2
1300    noarch/base/pkglist.classic.bz2
$

Из этого видно следующее: для noarch пакетов переупорядочивание
по %{SOURCERPM} почти ничего не дает.  Это связано с тем, что noarch
пакеты реже распиливают, а при распиливании названия подпакетов реже
отличаются по префиксу (то есть глобального переупорядочивания, которое
может повысить степень сжатия, как напр. в случае с lib%name и %name,
не происходит).

Для x86_64 экономия заметна даже без генерации changelog'ов (2421/2384 =
1.6%, за счёт лучшего совпадения других атрибутов подпакетов),
а особенно с changelog'ом (3536/3306 = 7%, за счёт лучшего сжатия
одинаковых changelog'ов подряд идущих подпакетов).

В принципе выгаданные несколько процентов позволяют мне с большей
уверенностью говорить о включении changelog'ов в репозитарий, хотя
общая картина остаётся скорее прежней: если включить changelog'и по
предложенной схеме, то размер скачиваемого при 'apt-get update'
увеличивается примерно на треть.

Вот патч на genpkglist.cc, я его плохо проверил, но вроде работает.
У меня уже патч на патче сидит и я пока не знаю как его лучше приложить
к тому что есть.

--- apt-0.5.15lorg2/tools/genpkglist.cc-	2008-05-18 00:48:01 +0400
+++ apt-0.5.15lorg2/tools/genpkglist.cc	2008-05-18 05:14:06 +0400
@@ -320,7 +320,7 @@ done:
 }
 
 bool copyFields(Header h, Header newHeader,
-		FILE *idxfile, const char *directory, char *filename,
+		FILE *idxfile, const char *directory, const char *filename,
 		unsigned filesize, map<string,UpdateInfo> &updateInfo,
 		bool fullFileList)
 {
@@ -460,99 +460,34 @@ void usage()
    cerr << "                 one preceding entry (if available)" <<endl;
 }
 
-
-
-#ifndef HAVE_SCANDIR
-// from glibc 1.09.1  mod'd by jmik, ins'd by asm, fix'd by sbi
-int alphasort(const void * a, const void * b)
+static void progress(int cur, int total)
 {
-  return strcmp ((*(struct dirent **) a)->d_name,
-                 (*(struct dirent **) b)->d_name);
+   if (cur > 1)
+      printf("\b\b\b\b\b\b\b\b\b\b");
+   printf(" %04i/%04i", cur, total);
+   fflush(stdout);
 }
 
-int scandir(const char * dir, struct dirent *** namelist, 
-        int (* select)(struct dirent *), 
-        int (* cmp)(const void *, const void *))
+struct rpmfile {
+   const char *basename;
+   const char *sourcerpm;
+};
 
+static
+int rpmfilecmp(const void *a, const void *b)
 {
-  DIR *dp = opendir (dir);
-  struct dirent **v = NULL;
-  size_t vsize = 0, i;
-  struct dirent *d;
-  int save;
-
-  if (dp == NULL)
-    return -1;
-
-  save = errno;
-  errno = 0;
-
-  i = 0;
-  while ((d = readdir (dp)) != NULL)
-    {
-    if (select == NULL || (*select) (d))
-      {
-        if (i == vsize)
-          {
-            struct dirent **newv;
-            if (vsize == 0)
-              vsize = 10;
-            else
-              vsize *= 2;
-            newv = (struct dirent **) realloc (v, vsize * sizeof (*v));
-            if (newv == NULL)
-              {
-              lose:
-                errno = ENOMEM;
-                break;
-              }
-            v = newv;
-          }
-
-        v[i] = (struct dirent *) malloc (d->d_reclen);
-        if (v[i] == NULL)
-          goto lose;
-
-        // *v[i++] = *d;
-	memcpy(v[i], d, d->d_reclen);
-	i++;
-      }
-    }
-
-  v[i] = NULL;
-
-  if (errno != 0)
-    {
-      save = errno;
-      (void) closedir (dp);
-      while (i > 0)
-        free (v[--i]);
-      free (v);
-      errno = save;
-      return -1;
-    }
-
-  (void) closedir (dp);
-  errno = save;
-
-  /* Sort the list if we have a comparison function to sort with.  */
-  if (cmp != NULL)
-    qsort (v, i, sizeof (struct dirent *), cmp);
-
-  *namelist = v;
-  return i;
+   const struct rpmfile *A = (struct rpmfile *)a;
+   const struct rpmfile *B = (struct rpmfile *)b;
+   int cmp = strcmp(A->sourcerpm, B->sourcerpm);
+   if (cmp)
+      return cmp;
+   return strcmp(A->basename, B->basename);
 }
-// end of new stuff from glibc
-#endif /* !HAVE_SCANDIR */
-
 
 int main(int argc, char ** argv) 
 {
    string rpmsdir;
    string pkglist_path;
-   FD_t outfd, fd;
-   struct dirent **dirEntries;
-   int entry_no, entry_cur;
    map<string,UpdateInfo> updateInfo;
    CachedMD5 *md5cache;
    char *op_dir;
@@ -561,13 +496,13 @@ int main(int argc, char ** argv) 
    char *op_update = NULL;
    long /* time_t */ changelog_since = 0;
    FILE *idxfile;
-   int i;
    bool fullFileList = false;
    bool progressBar = false;
    const char *pkgListSuffix = NULL;
    bool pkgListAppend = false;
    
    setlocale(LC_ALL, "C");
+   int i;
    for (i = 1; i < argc; i++) {
       if (strcmp(argv[i], "--index") == 0) {
 	 i++;
@@ -674,14 +609,16 @@ int main(int argc, char ** argv) 
 
    string dirtag = "RPMS." + string(op_suf);
 
-   entry_no = scandir(rpmsdir.c_str(), &dirEntries, selectDirent, alphasort);
-   if (entry_no < 0) {
-      cerr << "genpkglist: error opening directory " << rpmsdir << ":"
-	  << strerror(errno);
-      return 1;
+   if (chdir(rpmsdir.c_str())) {
+      perror(rpmsdir.c_str());
+      exit(1);
+   }
+
+   glob_t gl;
+   if (glob("*.rpm", 0, NULL, &gl)) {
+      cerr << rpmsdir << "/" << "*.rpm: glob failed" <<endl;
+      exit(1);
    }
-   
-   chdir(rpmsdir.c_str());
    
    if (pkgListSuffix != NULL)
 	   pkglist_path = pkglist_path + "/base/pkglist." + pkgListSuffix;
@@ -689,6 +626,7 @@ int main(int argc, char ** argv) 
 	   pkglist_path = pkglist_path + "/base/pkglist." + op_suf;
    
    
+   FD_t outfd;
    if (pkgListAppend == true && FileExists(pkglist_path)) {
       outfd = fdOpen(pkglist_path.c_str(), O_WRONLY|O_APPEND, 0644);
    } else {
@@ -711,30 +649,54 @@ int main(int argc, char ** argv) 
    int isSource;
 #endif   
 
-   if (!fullFileList) {
-      // ALT: file list cannot be stripped in a dumb manner -- this is going
-      // to produce unmet dependencies.  First pass is required to initialize
-      // certain data structures.
-      for (entry_cur = 0; entry_cur < entry_no; entry_cur++) {
-         if (progressBar) {
-            if (entry_cur)
-               printf("\b\b\b\b\b\b\b\b\b\b");
-            printf(" %04i/%04i", entry_cur + 1, entry_no);
-            fflush(stdout);
-         }
+   struct rpmfile *rpms = new struct rpmfile[gl.gl_pathc];
+   int ix, n = 0;
+
+   for (ix = 0; ix < gl.gl_pathc; ix++) {
+         if (progressBar)
+	    progress(ix+1, gl.gl_pathc);
+	 
+	 const char *basename = gl.gl_pathv[ix];
+         FD_t fd = Fopen(basename, "r");
+         if (!fd) {
+	    cerr << "Warning: " << basename << ": " << strerror(errno) <<endl;
+	    continue;
+	 }
 
-         fd = fdOpen(dirEntries[entry_cur]->d_name, O_RDONLY, 0666);
-         if (!fd)
-            continue;
          int rc;
          Header h;
 #if RPM_VERSION >= 0x040100
          rc = rpmReadPackageFile(ts, fd, dirEntries[entry_cur]->d_name, &h);
-         if (rc == RPMRC_OK || rc == RPMRC_NOTTRUSTED || rc == RPMRC_NOKEY) {
+         if (rc == RPMRC_OK || rc == RPMRC_NOTTRUSTED || rc == RPMRC_NOKEY)
 #else
          rc = rpmReadPackageHeader(fd, &h, &isSource, NULL, NULL);
-         if (rc == 0) {
+         if (rc == 0)
 #endif
+	 {
+	    ; // good
+	 }
+	 else {
+	    cerr << "Warning: " << basename << ": cannot read package header" <<endl;
+	    continue;
+	 }
+	 
+	 const char *sourcerpm;
+	 rc = headerGetEntry(h, RPMTAG_SOURCERPM, NULL, (void**)&sourcerpm, NULL);
+	 if (!(rc == 1)) {
+	    cerr << "Warning: " << basename << ": no SOURCERPM tag" <<endl;
+	    continue;
+	 }
+
+	 sourcerpm = strdup(sourcerpm);
+	 assert(sourcerpm);
+	 rpms[n].basename = basename;
+	 rpms[n].sourcerpm = sourcerpm;
+	 n++;
+	 
+      // ALT: file list cannot be stripped in a dumb manner -- this is going
+      // to produce unmet dependencies.  First pass is required to initialize
+      // certain data structures.
+	 if (!fullFileList) {
             // path-like Requires
             int_32 reqtype = 0;
             const char **requires = NULL;
@@ -776,37 +738,35 @@ int main(int argc, char ** argv) 
             headerFreeTag(h, dn, (rpmTagType)dnt);
             headerFreeTag(h, di, (rpmTagType)dit);
             
-            headerFree(h);
          }
+	 headerFree(h);
          Fclose(fd);
-      }
    }
-   for (entry_cur = 0; entry_cur < entry_no; entry_cur++) {
+
+   qsort(rpms, n, sizeof(struct rpmfile), rpmfilecmp);
+
+   for (ix = 0; ix < n; ix++) {
       struct stat sb;
 
-      if (progressBar) {
-         if (entry_cur)
-            printf("\b\b\b\b\b\b\b\b\b\b");
-         printf(" %04i/%04i", entry_cur + 1, entry_no);
-         fflush(stdout);
-      }
+      if (progressBar)
+	 progress(ix+1, n);
 
-      if (stat(dirEntries[entry_cur]->d_name, &sb) < 0) {
-	    cerr << "\nWarning: " << strerror(errno) << ": " << 
-		    dirEntries[entry_cur]->d_name << endl;
-	    continue;
+      const char *basename = rpms[ix].basename;
+
+      if (stat(basename, &sb) < 0) {
+	    cerr << "Fatal: " << basename << ": " << strerror(errno) <<endl;
+	    exit(1);
       }
 
       {
 	 Header h;
 	 int rc;
 	 
-	 fd = fdOpen(dirEntries[entry_cur]->d_name, O_RDONLY, 0666);
+	 FD_t fd = Fopen(basename, "r");
 
 	 if (!fd) {
-	    cerr << "\nWarning: " << strerror(errno) << ": " << 
-		    dirEntries[entry_cur]->d_name << endl;
-	    continue;
+	    cerr << "Fatal: " << basename << ": " << strerror(errno) <<endl;
+	    exit(1);
 	 }
 	 
 #if RPM_VERSION >= 0x040100
@@ -822,14 +782,13 @@ int main(int argc, char ** argv) 
 	    newHeader = headerNew();
 	    
 	    copyFields(h, newHeader, idxfile, dirtag.c_str(),
-		       dirEntries[entry_cur]->d_name,
+		       basename,
 		       sb.st_size, updateInfo, fullFileList);
 
 	    if (changelog_since > 0)
 	       copyChangelog(changelog_since, h, newHeader);
 
-	    md5cache->MD5ForFile(string(dirEntries[entry_cur]->d_name), 
-				 sb.st_mtime, md5);
+	    md5cache->MD5ForFile(string(basename), sb.st_mtime, md5);
 	    headerAddEntry(newHeader, CRPMTAG_MD5, RPM_STRING_TYPE, md5, 1);
 
 	    headerWrite(outfd, newHeader, HEADER_MAGIC_YES);
@@ -837,8 +796,8 @@ int main(int argc, char ** argv) 
 	    headerFree(newHeader);
 	    headerFree(h);
 	 } else {
-	    cerr << "\nWarning: Skipping malformed RPM: " << 
-		    dirEntries[entry_cur]->d_name << endl;
+	    cerr << "Fatal: " << basename << ": cannot read package header" <<endl;
+	    exit(1);
 	 }
 	 Fclose(fd);
       }

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Sun, May 18, 2008 at 06:07:51AM +0400, Alexey Tourbin wrote:
> В принципе выгаданные несколько процентов позволяют мне с большей
> уверенностью говорить о включении changelog'ов в репозитарий, хотя
> общая картина остаётся скорее прежней: если включить changelog'и по
> предложенной схеме, то размер скачиваемого при 'apt-get update'
> увеличивается примерно на треть.

В абсолютных цифрах это примерно 3.5M -> 4.5M.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> Я сделал предварительную реализацию сортировки по %{SOURCERPM}.
> Результаты теперь такие:

У меня вопрос: изменив сортировку по алфавиту на сортировку по 
%{SOURCERPM} ты не ухудшил скорость поиска `apt-cache search` ?

Не нужно ли ввести корректировку алгоритма поиска (apt-cache search), 
чтобы он искал только в первом changelog'е при условии что поле 
%{SOURCERPM} у нескольких пакетов в pkglist совпадает?

Вообще, очень неприятно что changelog'и дублируются в этой реализации.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3689 bytes --]

On Sun, May 18, 2008 at 01:26:20PM +0400, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> >Я сделал предварительную реализацию 
> >сортировки по %{SOURCERPM}.
> >Результаты теперь такие:
> 
> У меня вопрос: изменив сортировку по 
> алфавиту на сортировку по %{SOURCERPM} ты не 
> ухудшил скорость поиска `apt-cache search` ?

А как могла скорость ухудшиться?  Однако появилась особенность:
в выдаче 'apt-cache search' найденные пакеты отсортированы не по
названию, а по %{SOURCERPM}.

(Старое поведение)
$ apt-cache search apt |awk '$1~/apt\>/'
apt - Debian's Advanced Packaging Tool with RPM support
apt-conf-desktop - A set of apt configuration files for ALT Linux Desktop
apt-conf-server - A set of apt configuration files for ALT Linux Server
apt-conf-sisyphus - A set of apt configuration files for ALT Linux Sisyphus
apt-rsync - rsync method support for APT
apt-utils - Utilities to create APT repositaries (the indices)
capt - CAPT Linux driver
kio-apt - An apt:/ protocol in konqueror
libapt - APT's core libraries
libapt-devel - Development files and documentation for APT's core libs
apt-log - Log support for APT
apt-scripts - Lua scripts for APT
docs-alterator_apt-kirill - Extra packages
docs-packages_apt - Install and remove programs (packages)
$ 

(Новое поведение)
$ ./build/aptbox/apt-cache search apt |awk '$1~/apt\>/'
apt - Debian's Advanced Packaging Tool with RPM support
apt-rsync - rsync method support for APT
apt-utils - Utilities to create APT repositaries (the indices)
libapt - APT's core libraries
libapt-devel - Development files and documentation for APT's core libs
apt-conf-desktop - A set of apt configuration files for ALT Linux Desktop
apt-conf-server - A set of apt configuration files for ALT Linux Server
apt-conf-sisyphus - A set of apt configuration files for ALT Linux Sisyphus
capt - CAPT Linux driver
kio-apt - An apt:/ protocol in konqueror
apt-log - Log support for APT
apt-scripts - Lua scripts for APT
docs-alterator_apt-kirill - Extra packages
docs-packages_apt - Install and remove programs (packages)
$ 

Теперь libapt* "примыкает" к пакетам apt*.  В принципе это изменение
нельзя однозначно квалифицировать как нежелательное или неправильное,
потому что нарушение алфавитного порядка позволяет нам догадаться,
что речь идёт о подпакетах, собранных из одного src.rpm пакета
(группировку по src.rpm при поиске можно даже считать интересной фичей,
просто это информация здесь не выражена явно).

К тому же на самом деле сортировка действует только в пределах
репозитария, так что при переходе к noarch пакеты опять начинаются
с буквы "a".

> Не нужно ли ввести корректировку 
> алгоритма поиска (apt-cache search), чтобы он 
> искал только в первом changelog'е при условии 
> что поле %{SOURCERPM} у нескольких пакетов в 
> pkglist совпадает?

Наверное, нужно.  То есть при совпадении по changelog'у следовало
бы игнорировать все последующие (adjacent) пакеты с совпадающим SOURCERPM.
Но я боюсь что жесткая структурная декомпозиция снизу вверх, то есть
поиск идёт per header, и протощить нужную информацию будет сложновато.

Точнее, не знаю, нужно или не нужно.
Я пока ещё не добавил поиск по changelog'ам.

> Вообще, очень неприятно что changelog'и 
> дублируются в этой реализации.

Но если дубли сгруппировать, то они очень хорошо сжимаются.
Если же выносить дублирующуюся информацию в отдельное место,
то, прежде всего, придётся распустить Header как структуру;
а это дополнительный оверхед на bookkeeping + проверка целостности.

Попробуй распустить хедер на два "подхедера", сразу встанет вопрос,
соответствует ли первый подхедер второму или нет.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> А как могла скорость ухудшиться?

Я думал ты добавил changelog в поиск.

> Я пока ещё не добавил поиск по changelog'ам.

Я считаю что и не нужно добавлять. Потому что `apt-cache search` 
предназначен для поиска пакетов, а в случае подключения changelog'ов 
будут находиться пакеты в changelog'е которого содержится ключевое 
слово. Ты приводил пример с CVE, но такой тип поиска намного более 
редок чем обычный поиск пакета по ключевому слову. Если всё-таки 
кому-то хочется искать по ним, то он сможет воспользоваться --full.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Alexey Morozov]

В сообщении от Sunday 18 May 2008 02:00:34 Alexey Tourbin написал(а):

> На самом деле то что через apt нельзя посмотреть изменения в пакете
> это одна из основных претензий к апту.  Александр Боковой ещё
> в х**-знает-каком году писал, как он в Сане показывал наш synaptic,
> и первое что у него саны спросили это где посмотреть изменения
> обновляемых пакетов.

Да, кстати. Но это, кстати, особенность именно [нашего] apt-rpm, у 
дебианоубунтовцев в этом месте всё нормально, там изменения еще и по 
приоритету сортируются, что крайне полезно енд-лузеру, вроде меня, любящего 
красивые окошки и дружелюбные программки.

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

Хотя, конечно, приоритетность изменений, видимо, должна быть более 
комплексной. Что-то типа "характер изменений" (security, bugfix, enhancement, 
или всё вместе) и "величина изменений" (minor, intermediate, major). Только в 
этом случае "величина изменений" - это не просто константа для данного 
пакета, а некоторая кумулятивная характеристика, складывающаяся из характера 
изменений самого пакета и характера изменений сборочного окружения.

Что касается того, "сколько времени" хранить ченджлог в апте, то, думаю, было 
бы уместно оставлять не более одного major изменения.