On Tue, Aug 07, 2007 at 02:20:48AM +0400, Alexey Tourbin wrote:
> ЗАОСТРЯЮ ПРОБЛЕМУ "ПОЛУ-АНМЕТОВ".
> 
> 
> Это проблема проявляется тогда, когда зависимость имеет вид /ПУТЬ,
> но у соответствующего пакета не стоит Provides: /ПУТЬ.  На уровне
> rpm это не является unmet'ом: если при установке пакета с такой
> зависимостью имеется какой-либо другой пакет с файлом /ПУТЬ,
> то для rpm это "канает".
> 
> С другой стороны, apt видит такую зависимость именно как unmet.
> Вообще-то у апта к каждому пакету есть файловые листы, и он использует
> их для разрешения такого рода зависимостей.  Но при изготовлении
> репозитария аптовые листы у нас насильно "оптимизируются".
> 
> Два простых варианта решения это проблемы:
> 
> 1) Генерировать более полный content_index для hasher, чтобы любой путь
> более гарантированно трансформировался в название пакета (насколько
> более полный/гарантированно?).
> 
> 2) Восстановить файловые листы для апт.  Насколько потяжелеет
> pkglist.classic.bz2?

Если мыслей нет, то утро вечера мудренее.  Пока есть только идея
захачить hsh-sh-cache-contents-functions, чтобы он изготовлял
contents_index_all.gz.

Кстати, там есть ошибочка, из-за которой дупы могут не отлавливаться.

$ grep /sbin/ifup build/cache/contents/contents_index_bin 
/sbin/ifup      etcnet
/sbin/ifup      net-scripts
$

Это потому что net-scripts из i586 а etcnet из noarch.

--- /usr/bin/hsh-sh-cache-contents-functions-	2007-06-16 13:11:39 +0000
+++ /usr/bin/hsh-sh-cache-contents-functions	2007-08-06 23:29:22 +0000
@@ -195,6 +195,8 @@ create_contents()
 		Fatal 'Failed to create contents index.'
 	fi
 
+	sort -u -o "$contents" "$contents"
+
 	if ! LC_COLLATE=C prepare_contents "$tmpdir" >"$contents_index_bin"; then
 		rm -rf "$tmpdir"
 		Fatal 'Failed to prepare contents index.'