On Sat, Aug 11, 2007 at 08:13:24PM +0400, Dmitry V. Levin wrote:
> > Changelog since `0.5.15lorg2-alt12' follows:
> > commit 30e27b0f1c74b4f67354a6035fae3e210131bca1
> > Author: Alexey Tourbin <at@altlinux>
> > Date:   Sat Aug 11 20:01:05 2007 +0400
> > 
> >     apt-0.5.15lorg2-alt-genpkglist-reqfiles.patch
> >     
> >     genpkglist strips file lists by default (without --bloat option).
> >     It keeps only some "useful files" by using a few ad hoc patterns.
> >     
> >     This can break file-level dependencies.  Consider pkgA requires
> >     /usr/lib/foo1/bar, and pkgB owns this file without explicitly
> >     providing it.  Now if genpkglist strips /usr/lib/foo1/bar
> >     from pkgB file list, this is going to be an unmet dependency.
> >     
> >     This patch changes genpkglist behaviour, so that, when genpkglist
> >     is invoked without --bloat option, it first finds all file-level
> >     dependencies (something like "rpm -qaR |grep ^/").  This requires
> >     a separate pass.  The list of file-level dependencies is saved into
> >     "reqfiles" global variable.  And on the second (normal) pass, the
> >     function usefulFile() is modified to check the "reqfiles" variable;
> >     that is, it should keep a file in the file list if it's been required
> >     by some package in the repo.
> 
> Я не понял, эта информация кешируется или каждый запуск genpkglist будет
> дампить зависимости всех пакетов?

Эта информация кешируется, а каждый запуск genpkglist будет дампить
зависимости всех пакетов. :)

Суть в том, что в старом варианте genpkglist без опции --bloat сохраняет
пути в хедере (DIRNAMES, BASENAMES и DIRINDEXES) лишь частично, по
шаблонам usefulFile().  Теперь будет работать в два прохода: первый
прход -- дампит зависимости requires и сохраняет "file-level
dependencies"; на втором (обычном) проходе в usefulFile(), кроме
шаблонов, проверяется также список file-level dependencies.

Если вопрос по скорости работы, то попробуй с опцией --progress.
Но это очень зависит от работы буферного кеша.

> >     (Unfortunately, this patch does not solve all of the problems
> >     I want it to solve; we have separate repos for i586 and noarch --
> >     inter-repo file-level dependencies cannot be resolved this way.)
> Тогда зачем это изменение?

Потому что это правильно.  Если уж и обрезать файловые списки, то нужно
это делать с умом.  Оптимизация, которая даёт unmet'ы, это неправильная
оптимизация.  Данный патч делает всё возможное супротив оптимизаци,
которая чревата анметами.  К сожалению, этот патч не может сделать
также и невозможное.

Я вообще считаю что генерировать заведомо незамкнутые репозитарии (как
i586 и noarch у нас) это неправильно.  И одноврменно обрезать файловые
листы.