[devel] I: sonames versioned with symbols

[devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

Я нарисовал предварительную (и пока весьма несовершенную) реализацию
этого дела.  Суть этого дела в том, что сонеймы (имена библиотек)
будут предоставлять "множество символов", то есть функций (и переменных),
которые из них можно загрузить.  Соответственно при линковке можно
требовать символы, которые туда разрешаются - и это делается
автоматически в lib.req с помощью специальных возможностей ld.so/ldd.
http://git.altlinux.org/people/at/packages/rpm.git?a=shortlog;h=refs/heads/libhash

С целью тестирования я пересобрал (приватно) базовую систему; и теперь
например у пакета librpm появилась зависимость
Requires: libz.so.1()(64bit) >= set:gzclose;gzdopen;gzerror;gzflush;gzopen;gzread;gzseek;gzwrite

Соответственно у пакета zlib появился более длинная зависимость
Provides: libz.so.1()(64bit) = set:adler32;adler32_combine;compress;compress2;compressBound;crc32;...

set-версии надо будет переделать - вместо "poor man's" реализации, когда
символы просто конкатенируются, надо придумать какую-то схему
хеширования (чтобы версии у зависимостей были более "короткие").
Пожалуй напишу об этом подробнее - позже.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Sun, May 09, 2010 at 06:02:24PM +0400, Алексей Турбин wrote:

AT> Я нарисовал предварительную (и пока весьма несовершенную) реализацию
AT> этого дела.  Суть этого дела в том, что сонеймы (имена библиотек)
AT> будут предоставлять "множество символов", то есть функций (и переменных),
AT> которые из них можно загрузить.  Соответственно при линковке можно
AT> требовать символы, которые туда разрешаются - и это делается
AT> автоматически в lib.req с помощью специальных возможностей ld.so/ldd.
AT> http://git.altlinux.org/people/at/packages/rpm.git?a=shortlog;h=refs/heads/libhash
AT> С целью тестирования я пересобрал (приватно) базовую систему; и теперь
AT> например у пакета librpm появилась зависимость
AT> Requires: libz.so.1()(64bit) >= set:gzclose;gzdopen;gzerror;gzflush;gzopen;gzread;gzseek;gzwrite

А что будет, если, например:

пакет A требует зависимость libabc.so.1 >= set:func1

а пакет B провайдит libabc.so.1 = set:func2
?
мне только так кажется, или при этом зависимость будет удовлетворена
формально (хотя в действительно, очевидно, это не так)?


-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

On Sun, May 09, 2010 at 07:11:51PM +0400, Денис Смирнов wrote:
> On Sun, May 09, 2010 at 06:02:24PM +0400, Алексей Турбин wrote:
> 
> AT> Я нарисовал предварительную (и пока весьма несовершенную) реализацию
> AT> этого дела.  Суть этого дела в том, что сонеймы (имена библиотек)
> AT> будут предоставлять "множество символов", то есть функций (и переменных),
> AT> которые из них можно загрузить.  Соответственно при линковке можно
> AT> требовать символы, которые туда разрешаются - и это делается
> AT> автоматически в lib.req с помощью специальных возможностей ld.so/ldd.
> AT> http://git.altlinux.org/people/at/packages/rpm.git?a=shortlog;h=refs/heads/libhash
> AT> С целью тестирования я пересобрал (приватно) базовую систему; и теперь
> AT> например у пакета librpm появилась зависимость
> AT> Requires: libz.so.1()(64bit) >= set:gzclose;gzdopen;gzerror;gzflush;gzopen;gzread;gzseek;gzwrite
> 
> А что будет, если, например:
> 
> пакет A требует зависимость libabc.so.1 >= set:func1
> 
> а пакет B провайдит libabc.so.1 = set:func2
> ?
> мне только так кажется, или при этом зависимость будет удовлетворена
> формально (хотя в действительно, очевидно, это не так)?

Зависимость удовлетворена не будет.  set-зависимости обладают
специальной семантикой: Requires-зависимость будет удовлетворена,
только если requries-set является подмножеством provides-set.
http://git.altlinux.org/people/at/packages/rpm.git?a=commitdiff;h=acd1dd03

То есть версии у зависимостей вида "set:*" обрабатываются специальным
кодом который их "раскладывает" и дальше проверят вложение.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Sun, May 09, 2010 at 07:42:28PM +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

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

Только вот как при этом сделать чтобы базы rpm и apt не распухли?

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

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 не _тормозил_ на такой базе? 

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

On Mon, May 10, 2010 at 03:36:11AM +0400, Алексей Турбин wrote:

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

Любопытно. В случае реальной коллизии самое страшное что случится --
поставиться пакет, который поставиться не должен. Однако сейчас (при
отсутствии такой проверки) он и так поставиться. Значит ничего не
сломается, а дополнительная защита появится. Я правильно понимаю?

Тогда мне эта идея очень нравится.

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

Верю. А может ты бы посмотрел на apt по поводу оптимизации? У меня есть
мнение, что его тормоза при распухшей базе обходятся тем, что при apt-get
update может формироваться "оптимизированная" база.

Есть проблема с тем, что базы rpm и apt две разные, однако если мы
оптимизируем, то удаление пакета из системы для нас не страшно, страшно
-- добавление (если поставили rpm'ом вручную). И в этом случае придется
оптимизированную базу перегенерировать (или проигнорировать).

А даже элементарная оптимизация -- все requires на некие provides, которые
предоставляет только один пакет подменять requires на этот конкретный
пакет, а provides которые никто не requires -- просто удалять из
оптимизированой версии базы -- теоретически должно заметно ускорить
тормозной apt :)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]

On Mon, May 10, 2010 at 04:08:49AM +0400, Денис Смирнов wrote:
> On Mon, May 10, 2010 at 03:36:11AM +0400, Алексей Турбин wrote:
> 
> AT> Чудес не бывает, информация должна быть каким-то образом представлена.
> AT> Вопрос только в том какая цена будет казаться нам приемлемой.  Если
> AT> придумать изощренный метод хеширования, то нужно, грубо говоря, примерно
> AT> 20 битов на символ полной энтропии (то есть примерно 3.3 буквы в
> AT> base64).  Есть теоретическая оценка что с надежностью 0.1% нужно 12
> AT> битов энтропии.  Короче это сложная тема, но пока можно считать, что
> AT> в "нормальной" (а не модельной, как сейчас) реализации потребуется
> AT> примерно 3 буквы на символ.
> AT> Конечно, символов бывает много, и версия может получиться очень длинной.
> AT> Так что даже неприлично показать. :)
> 
> Любопытно. В случае реальной коллизии самое страшное что случится --
> поставиться пакет, который поставиться не должен. Однако сейчас (при
> отсутствии такой проверки) он и так поставиться. Значит ничего не
> сломается, а дополнительная защита появится. Я правильно понимаю?
> 
> Тогда мне эта идея очень нравится.

Модельная реализация дает полную гарантию, как страховой полис.
Гарантия состоит в том, что символы будут разрешаться не хуже,
чем при сборке пакета (на уровне ld.so).

Можно сильно сэкономить, если ввести вероятностное хеширование
с контролируемой односторонней ошибкой.  Тогда да, будет
"дополнительная защита" (а не полная гарантия), которая
однако же срабатывает "почти всегда".

> AT> Понимаешь, все эти проблемы тормозов - мои в конечном счете.
> AT> А я не предлагаю утопических проектов. :)
> 
> Верю. А может ты бы посмотрел на apt по поводу оптимизации? У меня есть
> мнение, что его тормоза при распухшей базе обходятся тем, что при apt-get
> update может формироваться "оптимизированная" база.

Проблем с аптом особо нет - апт устроен менее глупо (точнее, менее
примитивно), чем rpm.  В апте есть структура данных называется Cache
предназначена для быстрого перехода между связанными пакетами (e.g. для
разрешения зависимостей).  В rpm такой структуры данных нет, там всё
делается более примитивно через "индексы".

Короче никакой "базы апта" нет.
И лучше не забивай себе голову всякой...

> Есть проблема с тем, что базы rpm и apt две разные, однако если мы
> оптимизируем, то удаление пакета из системы для нас не страшно, страшно
> -- добавление (если поставили rpm'ом вручную). И в этом случае придется
> оптимизированную базу перегенерировать (или проигнорировать).
> 
> А даже элементарная оптимизация -- все requires на некие provides, которые
> предоставляет только один пакет подменять requires на этот конкретный
> пакет, а provides которые никто не requires -- просто удалять из
> оптимизированой версии базы -- теоретически должно заметно ускорить
> тормозной apt :)

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Mon, May 10, 2010 at 04:58:09AM +0400, Алексей Турбин wrote:

AT> Модельная реализация дает полную гарантию, как страховой полис.

Надеюсь что все-таки надежнее чем полис ;)

AT> Гарантия состоит в том, что символы будут разрешаться не хуже,
AT> чем при сборке пакета (на уровне ld.so).
AT> Можно сильно сэкономить, если ввести вероятностное хеширование
AT> с контролируемой односторонней ошибкой.  Тогда да, будет
AT> "дополнительная защита" (а не полная гарантия), которая
AT> однако же срабатывает "почти всегда".

Насколько я понимаю, это даст только экономию места на диске + возможно
ускорение за счет времени чтения с диска. Не уверен что это настолько
существенно чтобы уменьшать надежность.

А если хэширование заменить сжатием? Элементарный gzip дал уже для примера
с libwireshark ~5 байт на символ. Там где символов много, в их именах
много повторяющихся участков, и особенно много повторяющихся префиксов.

Что если попробовать представление в виде деревьев? Может ли это дать
существенную экономию в объеме и скорости?

AT> Проблем с аптом особо нет - апт устроен менее глупо (точнее, менее
AT> примитивно), чем rpm.  В апте есть структура данных называется Cache
AT> предназначена для быстрого перехода между связанными пакетами (e.g. для
AT> разрешения зависимостей).  В rpm такой структуры данных нет, там всё
AT> делается более примитивно через "индексы".
AT> Короче никакой "базы апта" нет.
AT> И лучше не забивай себе голову всякой...

Понял :)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Michael Shigorin]

On Mon, May 10, 2010 at 03:36:11AM +0400, Alexey Tourbin wrote:
> Есть теоретическая оценка что с надежностью 0.1% нужно 12 битов
> энтропии.  Короче это сложная тема, но пока можно считать, что
> в "нормальной" (а не модельной, как сейчас) реализации
> потребуется примерно 3 буквы на символ.

Может, fingerprint theory пригодится?  Вот тут разобрано
применительно к органическим молекулам с несколькими прикладными
приёмами насчёт грубого/быстрого (притом надёжного) отсеивания и
последующей точной пристрелки:

http://www.daylight.com/dayhtml/doc/theory/theory.finger.html

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: sonames versioned with symbols

[Alexey Borovskoy]

* Понедельник 10 мая 2010 Денис Смирнов

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

Траффик не везде дешевый и каналы не везде мегабитные.

Может бы задачу с межбиблиотечными зависимостями можно решить 
каким-то другим способом?

-- 
Алексей.
GPG key fingerprint
DBB3 1832 13C6 5C96 4A58  4AFF 78F7 159F 66AD 8D7E

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On Mon, May 10, 2010 at 12:25:53PM +1200, Alexey Borovskoy wrote:
> * Понедельник 10 мая 2010 Денис Смирнов
> > Только вот как при этом сделать чтобы базы rpm и apt не
> >  распухли?
> > 
> > Или даже так -- с учетом того что трафик и диски нынче
> >  относительно дешевые, как сделать чтобы apt не _тормозил_ на
> >  такой базе?
> 
> Траффик не везде дешевый и каналы не везде мегабитные.

А кое-где люди землю жрут.

> Может бы задачу с межбиблиотечными зависимостями можно решить 
> каким-то другим способом?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Mon, May 10, 2010 at 04:43:08AM +0400, Alexey Tourbin wrote:
> On Mon, May 10, 2010 at 12:25:53PM +1200, Alexey Borovskoy wrote:
> > Траффик не везде дешевый и каналы не везде мегабитные.
> А кое-где люди землю жрут.

Я не хотел Вас задеть.  А также ранее я писал что интересуюсь
"практичной реализацией" и т.п.  Короче предлагаю замять мою
нетактичную реплику.

> > Может бы задачу с межбиблиотечными зависимостями можно решить 
> > каким-то другим способом?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Alexey Borovskoy]

* Понедельник 10 мая 2010 Alexey Tourbin

> On Mon, May 10, 2010 at 04:43:08AM +0400, Alexey Tourbin wrote:
> > On Mon, May 10, 2010 at 12:25:53PM +1200, Alexey Borovskoy 
wrote:
> > > Траффик не везде дешевый и каналы не везде мегабитные.
> >
> > А кое-где люди землю жрут.
> 
> Я не хотел Вас задеть.  А также ранее я писал что интересуюсь
> "практичной реализацией" и т.п.  Короче предлагаю замять мою
> нетактичную реплику.

Всё нормально.
 
> > > Может бы задачу с межбиблиотечными зависимостями можно
> > > решить каким-то другим способом?
> 


-- 
Алексей.
GPG key fingerprint
949B BC0E 2C44 7528 4F63  2753 E37A 9E3F 11F3 BDE1

Re: [devel] I: sonames versioned with symbols

[Alexander Bokovoy]

2010/5/9 Alexey Tourbin <at@altlinux.ru>:
> Я нарисовал предварительную (и пока весьма несовершенную) реализацию
> этого дела.  Суть этого дела в том, что сонеймы (имена библиотек)
> будут предоставлять "множество символов", то есть функций (и переменных),
> которые из них можно загрузить.  Соответственно при линковке можно
> требовать символы, которые туда разрешаются - и это делается
> автоматически в lib.req с помощью специальных возможностей ld.so/ldd.
> http://git.altlinux.org/people/at/packages/rpm.git?a=shortlog;h=refs/heads/libhash
>
> С целью тестирования я пересобрал (приватно) базовую систему; и теперь
> например у пакета librpm появилась зависимость
> Requires: libz.so.1()(64bit) >= set:gzclose;gzdopen;gzerror;gzflush;gzopen;gzread;gzseek;gzwrite
>
> Соответственно у пакета zlib появился более длинная зависимость
> Provides: libz.so.1()(64bit) = set:adler32;adler32_combine;compress;compress2;compressBound;crc32;...
>
> set-версии надо будет переделать - вместо "poor man's" реализации, когда
> символы просто конкатенируются, надо придумать какую-то схему
> хеширования (чтобы версии у зависимостей были более "короткие").
> Пожалуй напишу об этом подробнее - позже.
Такой механизм можно использовать для выражения сервисных зависимостей
между сложными пакетными группами?

Provides: infrastructure =
set:file-server;domain-controller;dns-server;ldap-server;...;cifs-client

Provides: infrastructure = set:nfs-server

Provides: infrastructure = set:nfs-client

и

Requires: infrastructure >= set:nfs-server;ldap-server;dns-server;file-server;

Можно ли объявлять множества, объединяемые из Provides: разных
пакетов? Так, чтобы Provides: infrastructure = set:...; можно было
"пополнять" из разных пакетов?

-- 
/ Alexander Bokovoy

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]

On Mon, May 10, 2010 at 06:29:09AM +0300, Alexander Bokovoy wrote:
> 2010/5/9 Alexey Tourbin <at@altlinux.ru>:
> > Я нарисовал предварительную (и пока весьма несовершенную) реализацию
> > этого дела.  Суть этого дела в том, что сонеймы (имена библиотек)
> > будут предоставлять "множество символов", то есть функций (и переменных),
> > которые из них можно загрузить.  Соответственно при линковке можно
> > требовать символы, которые туда разрешаются - и это делается
> > автоматически в lib.req с помощью специальных возможностей ld.so/ldd.
> > http://git.altlinux.org/people/at/packages/rpm.git?a=shortlog;h=refs/heads/libhash
> >
> > С целью тестирования я пересобрал (приватно) базовую систему; и теперь
> > например у пакета librpm появилась зависимость
> > Requires: libz.so.1()(64bit) >= set:gzclose;gzdopen;gzerror;gzflush;gzopen;gzread;gzseek;gzwrite
> >
> > Соответственно у пакета zlib появился более длинная зависимость
> > Provides: libz.so.1()(64bit) = set:adler32;adler32_combine;compress;compress2;compressBound;crc32;...
> >
> > set-версии надо будет переделать - вместо "poor man's" реализации, когда
> > символы просто конкатенируются, надо придумать какую-то схему
> > хеширования (чтобы версии у зависимостей были более "короткие").
> > Пожалуй напишу об этом подробнее - позже.
> Такой механизм можно использовать для выражения сервисных зависимостей
> между сложными пакетными группами?

Предполагается реализовать общий механизм "множество строк" (или
элементов) в виде версии.  Использовать его дальше можно как угодно,
но есть интерес №1 сделать таким образом зависимости на библиотеки.

> Provides: infrastructure =
> set:file-server;domain-controller;dns-server;ldap-server;...;cifs-client
> 
> Provides: infrastructure = set:nfs-server
> 
> Provides: infrastructure = set:nfs-client
> 
> и
> 
> Requires: infrastructure >= set:nfs-server;ldap-server;dns-server;file-server;
> 
> Можно ли объявлять множества, объединяемые из Provides: разных
> пакетов? Так, чтобы Provides: infrastructure = set:...; можно было
> "пополнять" из разных пакетов?

Нет, объединять Provides нельзя.  Какой-то один Provides может
удовлетворить какой-то конкретный Requires (такова логика работы rpm).
В этом есть смысл: либо какая-то одна библиотека предоставляет всё что
нам нужно, либо какой тогда смысл если есть две библиотеки с одинаковым
именем...  Но можно расщепить Requires!

Для твоего примера "infrastructure" использовать set-dependencies
кажется оверкиллом.  Ты можешь просто требовать infrastructure-nfs-server
или infrastructure = nfs-server или как старый добрый пример просто MTA.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Anton V. Boyarshinov]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Доброе время суток!
Меня тут посетила идея: как можно сделать то же самое, но заходя с
другой стороны.

При сборке библиотеки можно формировать список предоставляемых ей
символов и коммитить в отдельный бранч в gears (или в отдельный
репозиторий). А при сборке клиента этой библиотеки, основываясь на
сохранённой информации о истории символов, автоматически ставить
версионированную зависимость. Сильнее загружаем сборочный сервер, но
зато облегчаем жизнь apt-у у всех пользователей.

Антон

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Aleksey Novodvorsky]

14 мая 2010 г. 0:51 пользователь Anton V. Boyarshinov
<boyarsh@altlinux.org> написал:
> Доброе время суток!
> Меня тут посетила идея: как можно сделать то же самое, но заходя с
> другой стороны.
>
> При сборке библиотеки можно формировать список предоставляемых ей
> символов и коммитить в отдельный бранч в gears (или в отдельный
> репозиторий). А при сборке клиента этой библиотеки, основываясь на
> сохранённой информации о истории символов, автоматически ставить
> версионированную зависимость. Сильнее загружаем сборочный сервер, но
> зато облегчаем жизнь apt-у у всех пользователей.


Меня смущает ухудшение дистрибутивности сборочной среды. Вообще, нужно
точно определить, что мы считаем сборочной средой и как ее можно
развернуть в произвольном месте. rpm+src.rpm, например, уже не
содержат всего необходимого для сборки если не пакетов, то
дистрибутивов, нужно лезть в git к boyarsh@. А теперь нужно будет еще
репозиторий символов устанавливать? Это возможно в принципе, но нужно
озаботиться простой и документированной дистрибьюцией всей сборочницы.

Rgrds, Алексей

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Fri, May 14, 2010 at 01:01:13AM +0400, Aleksey Novodvorsky wrote:
> 14 мая 2010 г. 0:51 пользователь Anton V. Boyarshinov
> <boyarsh@altlinux.org> написал:
> > Доброе время суток!
> > Меня тут посетила идея: как можно сделать то же самое, но заходя с
> > другой стороны.
> >
> > При сборке библиотеки можно формировать список предоставляемых ей
> > символов и коммитить в отдельный бранч в gears (или в отдельный
> > репозиторий). А при сборке клиента этой библиотеки, основываясь на
> > сохранённой информации о истории символов, автоматически ставить
> > версионированную зависимость. Сильнее загружаем сборочный сервер, но
> > зато облегчаем жизнь apt-у у всех пользователей.
> 
> Меня смущает ухудшение дистрибутивности сборочной среды. Вообще, нужно
> точно определить, что мы считаем сборочной средой и как ее можно

Вы не смущайтесь на тему что там что-то не сходится; потому что там всё
сходится.  Лучше смущайтесь на тему что мне мало денег отвесили.

> развернуть в произвольном месте. rpm+src.rpm, например, уже не
> содержат всего необходимого для сборки если не пакетов, то
> дистрибутивов, нужно лезть в git к boyarsh@. А теперь нужно будет еще
> репозиторий символов устанавливать? Это возможно в принципе, но нужно
> озаботиться простой и документированной дистрибьюцией всей сборочницы.
> 
> Rgrds, Алексей

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Yuri N. Sedunov]

В Птн, 14/05/2010 в 01:23 +0400, Alexey Tourbin пишет:

> 
> Вы не смущайтесь на тему что там что-то не сходится; потому что там всё
> сходится.  Лучше смущайтесь на тему что мне мало денег отвесили.
> 

А хер ли ж ты, Лёша Турбин, согласился делать столь сложную работу за
столь мало денег? Тем паче, что, собственно, делать её так сложно тебя
никто и не просил.

-- 
Yuri N. Sedunov

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Fri, May 14, 2010 at 02:23:20AM +0400, Yuri N. Sedunov wrote:
> В Птн, 14/05/2010 в 01:23 +0400, Alexey Tourbin пишет:
> > Вы не смущайтесь на тему что там что-то не сходится; потому что там всё
> > сходится.  Лучше смущайтесь на тему что мне мало денег отвесили.
> 
> А хер ли ж ты, Лёша Турбин, согласился делать столь сложную работу за
> столь мало денег? Тем паче, что, собственно, делать её так сложно тебя
> никто и не просил.

И щас мы всласть поругаемся на эту тему!  Кому сколько денег дали.
Алексей Турбин неровно дышит и высовывает язык как собака.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Michael Shigorin]

On Fri, May 14, 2010 at 01:01:13AM +0400, Aleksey Novodvorsky wrote:
> rpm+src.rpm, например, уже не содержат всего необходимого для
> сборки если не пакетов, то дистрибутивов, нужно лезть в git к
> boyarsh@.

Кажется, mkimage-profiles-desktop всё так же можно свернуть
в пакет, нет?

PS: прошу прощения за поднимание старого треда -- не получалось
залезть в него месяц тому.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: sonames versioned with symbols

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Fri, May 14, 2010 at 12:51:47AM +0400, Anton V. Boyarshinov wrote:
> Доброе время суток!
> Меня тут посетила идея: как можно сделать то же самое, но заходя с
> другой стороны.
> 
> При сборке библиотеки можно формировать список предоставляемых ей
> символов и коммитить в отдельный бранч в gears (или в отдельный
> репозиторий). А при сборке клиента этой библиотеки, основываясь на
> сохранённой информации о истории символов, автоматически ставить
> версионированную зависимость. Сильнее загружаем сборочный сервер, но
> зато облегчаем жизнь apt-у у всех пользователей.

Дело в том что символы иногда исчезают, то есть при увеличении версии
не всегда сохраняется обратная совместимость.  Например Дмитрий Левин
однажды собрал пакет iptables и там была библиотека libipt.  И значит
раз так оказалось что после этого какой-то iptables-module-* символов
недосчитался.  И его за это неглядя удалили.
http://www.mail-archive.com/sisyphus-incominger@lists.altlinux.org/msg88826.html

Короче не лезьте куда не понимаете.  Дело именно в том что множество
требуемых символов должно быть подмножеством предоставляемых символов.
Заменить это более-менее ничем нельзя.  Проверка вложения - принципиальна!

> Антон

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Anton V. Boyarshinov]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Fri, 14 May 2010 01:06:40 +0400 Alexey Tourbin wrote:

> Дело в том что символы иногда исчезают, то есть при увеличении версии
> не всегда сохраняется обратная совместимость.  Например Дмитрий Левин
> однажды собрал пакет iptables и там была библиотека libipt.  И значит
> раз так оказалось что после этого какой-то iptables-module-* символов
> недосчитался.  И его за это неглядя удалили.
Ну так ничто не мешает при сборке библиотеки, аналогично,
автоматически ставить ей версионированный conflicts на старые пакеты,
которые требовали тех символов, которых сейчас нет.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

On Fri, May 14, 2010 at 04:01:22PM +0400, Anton V. Boyarshinov wrote:

AVB> Ну так ничто не мешает при сборке библиотеки, аналогично,
AVB> автоматически ставить ей версионированный conflicts на старые пакеты,
AVB> которые требовали тех символов, которых сейчас нет.

Вот у нас есть libA с символом bar.
Вот у нас есть пакет B, требующий libA с символом bar.
При сборке пакета libA новой версии, мы должны поставить конфликт на все
версии пакета B, которые требуют символ bar.

Причем вполне вероятно что пакет B версии 1 его не требовал, версии 2 стал
требовать, версии 3 перестал требовать.

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

Мне кажется что это решение чрезмерно сложное. Вариант с set хоть и
раздувает базы, но зато надежен. IMHO это важнее.

Думаю что вопрос может стоять только в том, как сэкономить дисковое
пространство (и трафик), а также как сделать првоерку set-зависимостей
максимально быстрыми.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: sonames versioned with symbols

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Fri, May 14, 2010 at 04:01:22PM +0400, Anton V. Boyarshinov wrote:

AVB> Ну так ничто не мешает при сборке библиотеки, аналогично,
AVB> автоматически ставить ей версионированный conflicts на старые пакеты,
AVB> которые требовали тех символов, которых сейчас нет.

Кроме того, такое решение требует анализировать всю историю каждого
пакета.

Кстати я уже давно предлагаю аналогичное решение для проблемы
обновляемости (при переезде файлов между пакетами не всегда проставляют
корректные конфликты на версии), однако эта задача достаточно сложна чтобы
никто не хотел за нее браться :)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]