On Sun, May 09, 2010 at 10:56:12PM +0400, Денис Смирнов wrote:
> AT> Зависимость удовлетворена не будет.  set-зависимости обладают
> AT> специальной семантикой: Requires-зависимость будет удовлетворена,
> AT> только если requries-set является подмножеством provides-set.
> AT> http://git.altlinux.org/people/at/packages/rpm.git?a=commitdiff;h=acd1dd03
> 
> Интересно. Правда есть один большущий недостаток:
> 
> # nm -D libc.so.6  | grep ' T ' | wc -l
> 1616
> 
> или еще веселее:
> # nm -D /usr/lib/libwireshark.so.0  | grep ' T ' | wc -l
> 5320

Чудес не бывает, информация должна быть каким-то образом представлена.
Вопрос только в том какая цена будет казаться нам приемлемой.  Если
придумать изощренный метод хеширования, то нужно, грубо говоря, примерно
20 битов на символ полной энтропии (то есть примерно 3.3 буквы в
base64).  Есть теоретическая оценка что с надежностью 0.1% нужно 12
битов энтропии.  Короче это сложная тема, но пока можно считать, что
в "нормальной" (а не модельной, как сейчас) реализации потребуется
примерно 3 буквы на символ.

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

> AT> То есть версии у зависимостей вида "set:*" обрабатываются специальным
> AT> кодом который их "раскладывает" и дальше проверят вложение.
> AT> Вообще оказалось что в таком ракурсе возможна декомпозиция: с одной
> AT> стороны, как представить set-зависимости; с другой стороны, как их
> AT> формировать.  Оказывается это сводит сложную задачу к более простым
> AT> задачам. :)
> 
> Только вот как при этом сделать чтобы базы rpm и apt не распухли?

В этом интрига - возможна ли более практичная реализация.
Но пока обкатывается модельная реализация.

> Или даже так -- с учетом того что трафик и диски нынче относительно
> дешевые, как сделать чтобы apt не _тормозил_ на такой базе? 

Понимаешь, все эти проблемы тормозов - мои в конечном счете.
А я не предлагаю утопических проектов. :)