On Mon, Feb 16, 2009 at 06:00:32PM +0300, Sergey Bolshakov wrote:
> Обнаружен (внезапно!) некоторый неприятный момент в логике
> скрипта find-package, вид по ссылке:
> http://tinyurl.com/c7tzgq
> а именно: если однажды каким-либо образом в сборочной итерации N-1
> путь внешней зависимости не был разрешён в имя пакета, то такой путь
> будет внесён в зависимости пакета as is, и, таким образом, клауза
> 'The path is also "safe enough" if it is already required by someone'
> будет сама себя поддерживать сколь угодно большое количество
> пересборок, несмотря на то, что путь (уже) может быть разрешён в имя
> пакета, если пакет сборочно зависит, пусть непрямо, сам от себя.
> 
> На примере пакета openssl098:
> однажды в нём возникла зависимость на
> /usr/share/ca-certificates/ca-bundle.crt из-за ссылки
> /var/lib/ssl/cert.pem -> ../../../usr/share/ca-certificates/ca-bundle.crt,
> которая не могла (на тот момент) быть разрешена в ca-certificates.
> Последующие пересборки openssl098 ничего не принесут, поскольку 
> в сборочном окружении неизбежно оказывается предыдущий (кривой)
> openssl098, и клауза 'already required by, well, OMFG, ME!' не пустит
> пройти посмотреть в contents_index_all. Круг замкнулся.
> 
> Есть идеи ?

Идея такая: отображать путь в название пакета -- это вообще порочная
практика.  Эту практику приходится до сих пор поддерживать, потому
что у нас раздельно генерируются arch и $noarch репозитарии; и нет
способа учитывать взаимные влияния путей между этими репозитариями
(а все лишние пути обрезаются, чтобы уменьшить размер pkglist.classic).

Решение состоит в том, чтобы генерировать arch и noarch репозитарии
совместно.  Для этого достаточно поддерживать общий список путей,
которые нельзя урезать из pkglist.classic.

Короче, если путь точно известен, то лучше ставить зависимость
именно на этот точный путь.

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