From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=altlinux.org; s=dkim; h=Subject:In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Cc:To:From:Date:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UPv1+mA7e0CAyv5EZ/zKDZhN9oHECzULl+3skx5Bjs0=; b=BomfWOSO0TxTztNWd5kkAs2mWO 1g4PnWZRLPdF3mi8n4IqpBfkXtjQRqO1ucO4I0GsLgGcZe0V/Ge8cTuHpzQSk05gAj94iOeWOgNYi oGvUDq8j46aQR2jDIlCRxQmO9jr3/EIu4VsJA5JgSwGU+rOhSe6Z/G52LUNxsKZ7IpRo8AAJXut9o Cyclj8NkroExmPS314Zu3BQ9ND9o7qQIRbIpVjOg0im3HKtf8zeM1RqSD+/l+LtGGB7eQZ1m5lvSx 10W0qclliupp75jWets3QnagH5nF/oiK6phMCz5JBQL5gLRl2mjxghVMAo+MDfuxQAh/MKkegz59c wLpXeoXw==; Date: Mon, 16 Apr 2018 21:21:00 +0300 From: "Vladimir D. Seleznev" To: ALT Linux Team development discussions Message-ID: <20180416182100.GA16649@portlab> References: <20171023114102.GA24157@portlab> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-SA-Exim-Connect-IP: 93.191.18.90 X-SA-Exim-Mail-From: vseleznv@cs.msu.ru X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.cs.msu.ru) Cc: Ivan Zakharyaschev , "Dmitry V. Levin" Subject: Re: [devel] =?utf-8?q?versioned_set-versions=3B_was=3A_Re=3A_Qt5_?= =?utf-8?b?0Lgg0L/QvtC70L7QvNCw0L3QvdGL0LUg0L/Qu9Cw0LPQuNC90Ys=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 18:21:34 -0000 Archived-At: List-Archive: List-Post: On Sat, Dec 30, 2017 at 06:51:42AM +0300, Alexey Tourbin wrote: > 2017-12-29 16:38 GMT+03:00 Ivan Zakharyaschev : > > 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. С наступающим! -- С уважением, Владимир Селезнев