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

[Alexey Lubimov <avl@l14.ru>]

Dmitry V. Levin пишет:

>>При операции релиза (типа sandcl endpocket sisyphus) репозитария  можно 
>>хоть полдня ползать по репозитарию скриптами, раскрывая цепочки 
>>зависимостей (buildrequires - они железные и проверены в bte) пакетов и 
>>проверяя получившийся ряд на смешивание в них запрещеных сочетаний libdb.
> 
> 
> Это всё замечательно и можно применить прямо сейчас к текущему Сизифу, но
> в результате этой технически непростой работы можно будет лишь
> констатировать несовместимость.  Это само по себе хорошо, но работы по
> исправлению пакетов при этом меньше не станет.

Не совсем так.
Это должна быть в большинстве своем автоматическая работа.
Кладем новую библиотеку (руками и быстро), пересобираем репозитарий 
(автомат и долго) и выясняем две цифры - количество непересобранного и 
количество собранного неправильно. Если результат приемлим (ручная 
работа по правилам головой) - второй этап - тестирование в дедалусе 
(общественность и майнтейнеры). получили подтверждение работоспособности 
- в сизиф (общественность).


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

Для библиотеки либо прогнать тесткейсы на все случаи ее использования 
либо протестировать все программы, ее использующие. Для программ - 
прогнать все функции и убедится, что все работает так, как 
предполагается. Таких возможностей все равно нет. Стало быть надо быть 
поскромнее в своем стремлении вмешаться в процесс сборки программы  и 
уйти с общего для всех пользователей софтины тест-пространства.


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

Я говорил про авторов, а не про майнтейнеров. Автор разбирается в том, 
что он написал и имеет фидбек поболее майнтейнера отдельно взятого 
альтлинукса.

> 
>>Есть БТЕ. Вот пусть он и отсекает 100% лишнее. Остальное в сизифе просто 
>>не реализуемо в принципе.
> 
> 
> Значит, надо искать другие приёмы.

Пока что это означает закрытие дистров от расширений и выдавливание 
самих себя на обочину. Осталось зарезать libtool с тем, чтобы вообще 
ничего несизифного не собиралось и задача бужет выполнена.

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


как и потерянные в RPM_BUILD_ROOT файлы,  а за потерянный там *.pc 
можно и error выкатить

Конечно, диагностики всегда мало. :)


>>>>Рекурсивно разворачивать во время сборки все связи и завершать сборку 
>>>>при конфликте версий через другие линкуемые библиотеки имхо совсем 
>>>>другая задача. не так?
>>>
>>>Это не задача, это приём, который имеет смысл применить, хотя он и не
>>>может выявить всё, например, проблемы, возникающие при динамической
>>>загрузке модулей.
>>>
>>>Предложите, как лучше оформить интерфейс: как описать множество
>>>конфликтующих библиотек (которое будет меняться), как включать/выключать
>>>эту проверку при сборке того или иного пакета.
>>
>>Я вижу это таким образом.
>>
>>Должна быть практически не меняющаяся по именам умолчальная среда с 
>>одним претендентом по каждой альтернативе.
>>один 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, то именно так сейчас и происходит в Сизифе.

не совсем. Я должен в зависимостях указывать libqt3, libpng3, libdb4.1
А тут я в большинстве случаев указываю  libpng libdb4 , а подставляется 
дефолтная версия. Таким образом можно склонить большинство пакетов к 
одной версии либы и выделить действительно неработающие compat-требующие 
пакеты. Правда, не уверен, что это осуществимо...

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

пока не ловится и тем более не ловится автоматом.

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

Ну так наведеных зависимостей должен быть минимум. Для того в чрут и 
загоняем.
вот, к примеру, wine ис сизифа тащит за собой пол кде.
пересборка без кде либ полностью очищает его от зависимостей на них.

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

ну и славно. :)

> 
> 
>>>>Ни разу. Просто в спецслучаях указывать из нескольких альтенатив 
>>>>(libdb4.x) конкретную и пересобирая в bte обеспечить отсутствие 
>>>>конкурентов.
>>>
>>>Что такое спецслучаи и кто будет их отлавливать?

случаи, когда в репозитарии есть одновременно несколько одинаковых 
библиотек разных версий. Их даже по имени можно узнать. У них версия в 
нем сидит.

майнтейнер будет отлавливать по факту несборки или неработы с текущей 
версией библиотеки.

С этой версией не получилось - попробовать с другой. Получилось - либо 
портировать, либо так оставить, если никому это не надо.

Все как и сегодня, только диагностики больше и автоматизма.

>>
>>майнтейнер. прога то либо не будет собираться, либо работать.
>>
>>
>>>Что значит "обеспечить отсутствие конкурентов" - не ставить одновременно
>>>разные libdb4.X?  А если это невозможно?
>>
>>В бте?
>>такие случаи автоматом не решаются. Придется собирать консилиум 
>>майнтейнеров и решать, кого убрать. Как сегодня и происходит.
>>
Да, только сегодня убирают из репозитария, а я предлагаю убирать из БТЕ. 
Для этого консилиум не нужен. Он нужен только в случае совместного 
использования либы между собой и через себя. И только между 
заинтересованными майнтейнерами. А арбитр - проверка репозитария на 
выпавшие пакеты.

>>
>>>>По моему их не так уж и много. Кроме libdb4 и libpng разве что нибудь 
>>>>есть?
>>>
>>>Есть и будет появляться новое всегда, когда у библиотеки меняется soname.
>>
>>Не так. Это когда библиотеки обновляюти вместе с тем под другим именем 
>>оставляют старые версии. Если библиотеки просто обновляют, то либо прога 
>>собирается с ней, либо нет, но левых зависимостей все равно не возникает.
> 
> 
> Если у библиотеки достаточно разных пользователей, то её нельзя "просто"
> обновить, не сохранив прежнюю альтернативу.  Сколько времени она будет
> жить, в каждом конкретном случае бывает по-разному.
> 
Ну не надо скромничать. В свое время libgnomeprint(ui) 2.0 молча 
задавили, хотя она даже не мешала версии 2.2.

glabels, помнится тогда автоматом улетела и еще несколько неплохих 
программ...

Собственно, спецслучай от количества не перестает быть спецслучаем. Если 
есть несколько версий библиотеки  - майнтейнер должен либо ничего не 
выбирать и тогда должна ставится текущая дефолтная либа, либо честно 
выбрать соответствующий -compat.