[devel] symbols into dependencies

[Alexey Tourbin]

On Mon, Nov 16, 2009 at 01:43:52AM +0200, Led wrote:
> On Monday, 16 November 2009 01:11:56 Alexey Tourbin wrote:
> > > > Есть идея формировать зависимости на сонеймы с учетом символов.
> > > > Это может выглядеть так:
> > > >
> > > > 	%package -n libfoo
> > > > 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> > > >
> > > > 	%package -n foo
> > > > 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная
> > > > строка)
> > > >
> > > > То есть реализовать зависимости специального вида, которые представляют
> > > > собой "множество строк" (символов).  Вместо обычного сравнения версий
> > > > для таких зависимостей будет выполняться проверка, что requires set
> > > > является подмножеством provides set.
> > >
> > > А разве из существующих libfoo.so.1.1 и libfoo.so.1.2 не видно, что
> > > первая является подмножеством второй (из-за 1 < 2)? Зачем тогда ещё
> > > дополнительные хэши в зависимостях вводить?
> >
> > А как узнать в какой версии появился "неизвестный символ", в 1.1 или 1.2?
> > По идее для каждого символа нужно проставить зависимость на минимальную
> > версию, в которой этой символ появился (и потом выбрать максимальную
> > версию из всех).  Но у нас нету этой информации при сборке пакетов, где
> > когда какие символы появились.  А информация какие символы нужны всё-таки
> > есть, и (при нескольких "но" в районе ldd) это информация абсолютно
> > первичная и правдивая, straight from the horse's mouth.
> >
> > Кроме того, схема с комплементарным хешем отслеживает и удаление символов
> > (а не только добавление новых символов).
> 
> Т.е. отслеживать зависимости "досимвольно"? Спасибо, теперь понятно.

Да, "концептуальная" модель именно такая -- отслеживать символы
внутри сонейма.

Provides: (libfoo.so.1;foo_sym1,foo_sym2,foo_sym3,...)
Requires: (libfoo.so.1;foo_sym1,foo_sym2)

На практике as is это реализовать нельзя, потому что там символов будет
целый гигбайт.  В процессе обдумывания компактная схема вероятностного
представления "множества символов" с односторонней ошибкой не хуже 10^{-3}
и расходом порядка 12 бит на символ.

> > Надо как-то обеспечить бинарную совместимость (на уровне зависимостей).
> > Ясно что сейчас она по большому счёту никак не обеспечена, а затея
> > с нашенскими version scripts нужно признать в лучшем случае half
> > successful, а по гамбургскому счету она себя не оправдала.
> 
> К сожалению :(

Ну как сказать.  Если для всех библиотек аккуратно поддерживать version
scripts то будет хорошая бинарная совместимость.  Но это аргумент того
же рода что если все программы хорошо продумать и грамотно написать то
получится надёжная конструкция которую вообще менять не надо и которая
будет до конца работать.

А если конструкция разваливается то как бо и не грех подпереть
её палкой.  Без сожаления.

> > Так что 
> > видимо придётся решаться на крутые меры.
> 
> Предполагается ли Requires проставляться на полный хэш символов библиотеки, с 
> которой слинкован бинарник при сборке, или только на минимально необходимый и 
> достаточный хэш по факту используемых символов из этой библиотеки?

Полный набор символов.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20091116/6f9427b9/attachment-0001.bin>