[devel] versioned set-versions; was: Re: Qt5 и поломанные плагины

[Alexey Tourbin]

2017-12-29 16:38 GMT+03:00 Ivan Zakharyaschev <imz на altlinux.org>:
> On Mon, 23 Oct 2017, Vladimir D. Seleznev wrote:
>> После вчерашнего обновления Qt5 сломалась работоспособность uim-qt5,
>> который должен был работать как плагин к Qt5, но с новым релизом
>> последнего не подключается с такой диагностикой:
>>
>> Got keys from plugin meta data ("uim")
>> QFactoryLoader::QFactoryLoader() checking directory path
>> "/usr/bin/platforminputcontexts" ...
>> Cannot load library
>> /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
>>
>> (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
>> symbol _ZTI21QPlatformInputContext,
>> version Qt_5 not defined in file libQt5Gui.so.5 with link time reference)
>> QLibraryPrivate::loadPlugin failed on
>>
>> "/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so"
>> : "Cannot load library
>>
>> /usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
>>
>> (/usr/lib64/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so:
>> symbol _ZTI21QPlatformInputContext, version Qt_5 not defined in file
>> libQt5Gui.so.5 with link time reference)"
>>
>> По setversion всё в порядке, но видно, что символ
>> _ZTI21QPlatformInputContext в libQt5Gui.so.5 переехал с Qt_5 на
>> Qt_5_PRIVATE_API.
>>
>> Это чинится пересборкой uim'а с новым Qt5, но если бы я не использовал
>> uim-qt5, то и не заметил бы поломки, пока кто-нибудь из пользователей не
>> пожаловался бы, т.е. отслеживание работоспособности плагинов остаётся на
>> пользователях.
>>
>> Есть ли механизмы, с помощью которых можно было бы отслеживать подобные
>> поломки?  Если нет, то может у кого-нибудь есть идеи, как их можно было
>> бы отслеживать и добавить их в инфраструктуру сборочницы?
>
> Вспомнилось, что мы думали о разделении set на несколько множеств -- по
> версионированию. (Раз мы версионированию upstream-ов вообще не доверяем и
> имеем механизм set-versions.)
>
> Следов того обсуждения я сходу не нашёл.
>
> Отдельно требовалось продумать переходный период. Иметь Provides и со всем
> суммарным множеством (как сейчас), и разделённые. В случае наличия
> разделённых, генерировать Requires на разделённые.
>
> Во время перехода длина затронутых Provides возрастёт не больше, чем в два
> раза. После перехода общая длина будет примерно такая же, как сейчас.

Когда делались set-версии, я мыслил большей часть в терминах
наличия/отсутствия нужных функций; то есть это было улучшенное решение
проблемы "минимальной версии": найти минимальную версию библиотеки, в
которой все нужные функции предоставляются (улучшенное = с защитой от
удаления в последующих версиях).  Версионирование @ABI - это более
сложный, тонкий и опасный механизм.  Если разработчик его использует,
то он должен знать, что он делает.  Set-версии и версионирование @ABI
получились ортогональными механизмами: они никак друг другу не мешают
и вообще не интерферируют.

В данном случае разработчик как раз порезался своей опасной бритвой:
перенес символ из одного @ABI в другой, в результате чего ABI
изменился несовместимым образом. Разработчику надо повесить плакат над
рабочим местом: символ - это не бутерброд с колбасой, чтобы передавать
его из одного интерфейса в другой. Надо также отметить, что если бы
разработчик не делал вообще ничего, то проблемы бы не возникло.  (В
связи с этим возникают разные смешные вопросы: например, какова
производительность труда у этого разработчика?  Или же, выражаясь
словами Дреппера, можно ли подпускать его к клавиатуре?)

Два механизма были сделаны ортогональными вовсе не по недомыслию, а и
из-за сложной и компромиссной семантики разрешения версионированных
символов.  Ясно, что неверсионированный символ может разрешаться в
версионированный: sym -> sym на ABI, при условии, что символ sym на ABI
дефолтный (так что когда в библиотеке впервые появляется
версионирование, старые программы остаются работать без пересборки).
Менее очевидно, что и версионированный символ можно разрешиться в
неверсионированный: sym на ABI -> sym, при условии, что @ABI существует
кое-где как самостоятельная единица, а символ sym неверсионированный
(такой компромисс требуется в частности для того, чтобы работало
переопределение функций через LD_PRELOAD).  Получается, что если мы
хотим требовать символ sym на ABI, то не понятно, что нам требовать:
требование sym на ABI оказывается достаточным, но не необходимым. То есть
мы суперимпозируем на ld.so какую-то более приятную нам логику
разрешения символов, чем она есть на самом деле.

Единственное разрешение, которое ld.so точно не допускает, это
sym на ABI1 -> sym на ABI2.

Если все же накладывать на set-версии более приятную нам логику
разрешения символов, то можно было бы сделать следующее:

1) Требовать sym на ABI (требовать = хешировать как единый символ).
2) Предоставлять два символа: sym на ABI и sym (кроме недефолтных
симолов, для которых предоставлять только sym на ABI).

В еще более общем виде символы можно было бы хешировать как
sym(args)@ABI, поскольку сигнатуру функции можно узнать из DWARF (из
отладочной информации -g).  Тогда еще и получится защита от изменения
количества и типа аргументов. Об этом был мой доклад
https://github.com/svpv/protva2016/blob/master/protva2016.pdf
Временами я порываюсь этим заняться, но здесь есть слишком большой
нетехнический аспект.  Понимаете, когда у людей вроде вашего
руководства наконец-то появляются деньги, то они ставят это в заслугу
себе, а к другим относятся разве что снисходительнее. Туго набитые
карманы делают неинтересным вопрос об истинном положении вещей.
Впрочем, истинное положение вещей знает только Господ Бог, а ему до
нас кажется дела нету. Так что, как говорится, everyone must fend for
himself.  С наступающим!