Re: [devel] Re: .a vs .so

["Dmitry V. Levin" <ldv@altlinux.org>]

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

On Mon, Jan 12, 2004 at 01:21:26AM +0300, Alexey Lubimov wrote:
> Dmitry V. Levin пишет:
> >On Sun, Jan 11, 2004 at 07:57:34PM +0300, Алексей Любимов wrote:
> >>Dmitry V. Levin пишет:
> >>>On Sun, Jan 11, 2004 at 05:44:30PM +0300, Алексей Любимов wrote:
[...]
> >>>Если программа A была собрана с библиотекой L и с libdb4.1, а библиотека 
> >>>L
> >>>- с библиотекой libdb4.0, то во время запуска программы A в памяти
> >>>окажется и libdb4.0, и libdb4.1, и последствия этого будут ужасны.
> >>
> >>То, что  вся цепочка слинкованных программ должна быть связана с одной 
> >>версией libdb4.1 естественно.
> >>Но проблема то поднималась другая. Лишние связи, когда при сборке 
> >>программ могут быть подсунуты случайные версии и даже вперемешку. Разве 
> >>не так?
> >
> >Разве это другая задача?
> 
> Если речь идет именно о сборке программ в отдельном окружении без 
> конкурирующих пакетов - да.
> 
> В этом случае, есть "дефолтная" libdb4.0 и есть "несовместимая с ней 
> альтернатива" libdb4.1
> Программы собираются с libdb4.1
> Если программа требует именно libdb4-compat4.0, то она собирается с ним 
> и помечается, как libdb4-incompatible (на самом деле само по себе 
> buidrequires на libdb4-compat4.0 и будет этим признаком).
> 
> При операции релиза (типа sandcl endpocket sisyphus) репозитария  можно 
> хоть полдня ползать по репозитарию скриптами, раскрывая цепочки 
> зависимостей (buildrequires - они железные и проверены в bte) пакетов и 
> проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb.

Это всё замечательно и можно применить прямо сейчас к текущему Сизифу, но
в результате этой технически непростой работы можно будет лишь
констатировать несовместимость.  Это само по себе хорошо, но работы по
исправлению пакетов при этом меньше не станет.

Собственно говоря, это ответ на другой вопрос.

> >Как вы сможете отличить случайную линковку от неслучайной?
> 
> Никак. Это как в случае с мотоциклами. Сначала удаляют "лишний метал" со 
> ступицы, а потом теряют тормоза от перегрева.
> 
> Чтобы определить случайность линковки в общем случае, надо 
> протестировать программу по полной программе. Имхо, сизиф страдает от 
> таких "оптимизаций" поболее, чем от их отсутствия.

Это как (протестировать программу по полной программе)?

> У программ есть авторы и они обычно пишут список зависимостей. Далее 
> второе (расширяющее) приближение - сборка. На этом все начные методы 
> заканчиваются иначинается либо гадание либо тупая ручная статистика 
> учета возникших от оптимизации проблем.

Это очень оптимистичная оценка maintainer'ов, которые на самом деле очень
занятые и ленивые люди.  Не для всех пересобрать пакет раз в месяц
является выполнимой задачей.  Это надо иметь в виду.
> 
> Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто 
> не реализуемо в принципе.

Значит, надо искать другие приёмы.

> >Есть, конечно, некоторые приёмы, которые позволяют определить,
> >используется ли данной программой/библиотекой данная библиотека напрямую.
> 
> ldd?
> имхо не слишком надежно.

Конечно, это всего лишь warning, т.е. hint, если хотите.

> >>Рекурсивно разворачивать во время сборки все связи и завершать сборку 
> >>при конфликте версий через другие линкуемые библиотеки имхо совсем 
> >>другая задача. не так?
> >
> >Это не задача, это приём, который имеет смысл применить, хотя он и не
> >может выявить всё, например, проблемы, возникающие при динамической
> >загрузке модулей.
> >
> >Предложите, как лучше оформить интерфейс: как описать множество
> >конфликтующих библиотек (которое будет меняться), как включать/выключать
> >эту проверку при сборке того или иного пакета.
> 
> Я вижу это таким образом.
> 
> Должна быть практически не меняющаяся по именам умолчальная среда с 
> одним претендентом по каждой альтернативе.
> один gcc, glibc, libpng, libdb4 etc

Я вообще-то не об этом спрашивал.

> Альтернативы должны имет звания gcc-compat2.96 glibc-compat2.3 
> libng-compat2 libdb5-compat0 etc
> 
> Замечу, что основные имена являются скользящими. То есть libpng когда то 
> было версии 2, а потом без изменения имени становится версии3, а вот 
> -compat уже ссылаются на определенную версию и заморожены в таком 
> состоянии.
> 
> пакеты в нормальном состоянии должны требовать в BuildRequires  gcc, 
> glibc, libpng, libdb4.
> 
> Если пакет перестает собираться с новой версией и начинает требовать 
> -compat, то в BuildRequires вручную ставится зависимость на конкретный 
> compat.
> 
> Зависимость на -compat и является признаком замороженного на версии пакета.

Если опустить этот -compat, то именно так сейчас и происходит в Сизифе.

> Пишуться правила типа libdb conflicts libdb-compat
> 
> При пересборке факт смешанного использования библиотек через третью 
> программ не ловится. Его даже и ловить не надо.
> 
> После пересборки репозитария, по нему запускается скрипт проверки, 
> рекурсивно разворачивает зависимости и по правилам ловит факт смешивания 
> конфоиктующих альтернатив. После этого майнтейнеры решают, что делать. 
> То ли выбросить что либо из репозитария, то ли пересобрать по другому.

Можно и так ловить.

Но исправлять-то придётся, и не факт, что это будет просто сделать, если
одна из зависимостей наведённая.

> >>Я так понял, что если на этапе сборки не были доступны *.la, то во время 
> >>запуска программы хоть эти *la и не участвуют, но проблемы заложенные 
> >>недостатком информации при сборке остаются.
> >
> >
> >Я понимаю ситуацию ровно наоборот.
> >Если сборка (динамическая) идёт без .la-файлов, то никакой нехватки
> >информации нет, ни во время сборки, ни во время работы.
> >
> >Фактически, как уже было сказано неоднократно, библиотечные .la-файлы
> >бывают нужны для статической сборки, а модульные - для динамической
> >загрузки модулей средствами ltdl.
> 
> Да пока что вы противоречите друг другу с Морозовым, а я просто не 
> знаю, кто из вас прав :(

Противоречие только в предлагаемых подходах к разруливанию.  Во всём
остальном - полное взаимопонимание. :)

> >>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
> >>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие 
> >>конкурентов.
> >
> >Что такое спецслучаи и кто будет их отлавливать?
> 
> майнтейнер. прога то либо не будет собираться, либо работать.
> 
> >Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
> >разные libdb4.X?  А если это невозможно?
> 
> В бте?
> такие случаи автоматом не решаются. Придется собирать консилиум 
> майнтейнеров и решать, кого убрать. Как сегодня и происходит.
> 
> >>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь 
> >>есть?
> >
> >Есть и будет появляться новое всегда, когда у библиотеки меняется soname.
> 
> Не так. Это когда библиотеки обновляюти вместе с тем под другим именем 
> оставляют старые версии. Если библиотеки просто обновляют, то либо прога 
> собирается с ней, либо нет, но левых зависимостей все равно не возникает.

Если у библиотеки достаточно разных пользователей, то её нельзя "просто"
обновить, не сохранив прежнюю альтернативу.  Сколько времени она будет
жить, в каждом конкретном случае бывает по-разному.


-- 
ldv

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