On Mon, Aug 06, 2007 at 03:08:04PM +0400, Alexey Tourbin wrote:
> On Sat, Aug 04, 2007 at 01:41:56AM +0400, Dmitry V. Levin wrote:
> > Свою долю критики за неожиданные зависимости ты ещё получишь, не стоит
> > беспокоиться.
> 
> Кстати, только что обнаружил пример необходимости symlinks.req.
[...]
> То есть не хватает зависимости на consolehelper.  Правда, не факт
> что symlinks.req сможет проставить именно зависимость на
> consolehelper, т.к. find-package работает по очень урезанному
> contents_index.  В худшем случае появится "полу-unmet" на
> /usr/lib/consolehelper/helper.

Вот что теперь вылезает на openssl:

$ rpm -qpR libssl6-0.9.8d-alt3.athlon.rpm |grep /usr/share/
/usr/share/ca-certificates/ca-bundle.crt  
$ rpm -qlvp libssl6-0.9.8d-alt3.athlon.rpm |grep /usr/share/ca-
lrwxrwxrwx    1 root    root               48 Aug  7 01:42 /var/lib/ssl/cert.pem -> ../../../usr/share/ca-certificates/ca-bundle.crt
$

Это тот самый symlinks.req, которые добавляет зависимости на битые
симлинки.

The following packages have unmet dependencies:
  libssl6: Depends: /usr/share/ca-certificates/ca-bundle.crt but it is not installable


ЗАОСТРЯЮ ПРОБЛЕМУ "ПОЛУ-АНМЕТОВ".


Это проблема проявляется тогда, когда зависимость имеет вид /ПУТЬ,
но у соответствующего пакета не стоит Provides: /ПУТЬ.  На уровне
rpm это не является unmet'ом: если при установке пакета с такой
зависимостью имеется какой-либо другой пакет с файлом /ПУТЬ,
то для rpm это "канает".

С другой стороны, apt видит такую зависимость именно как unmet.
Вообще-то у апта к каждому пакету есть файловые листы, и он использует
их для разрешения такого рода зависимостей.  Но при изготовлении
репозитария аптовые листы у нас насильно "оптимизируются".

Два простых варианта решения это проблемы:

1) Генерировать более полный content_index для hasher, чтобы любой путь
более гарантированно трансформировался в название пакета (насколько
более полный/гарантированно?).

2) Восстановить файловые листы для апт.  Насколько потяжелеет
pkglist.classic.bz2?