[opensuse-packaging] %wx_requires, %wx_provides and %_use_internal_dependency_generator
Hi all and Stanislav, This week I've tried to implement auto requires/provides for erlang modules. One of the issues is wx-rpm-stuff specific to openSUSE. erlang does have wx-bindings package (it is allowed to compile some C/C++ code and load as build-in functions) and this way its spec contains disabling of internal dependency generator (and this disables fileattrs stuff). I can overcome it, and I do understand that there are strong reasons to implement this specific stuff controlling different ABI. However, internal dependency generator is enabled by default in rpm 4.10 and it seems to be powerful tool. Are there plans to adapt 'libwxfoo(variant)' syntax to IDG? Can find-wx-* stuff be implemented as suse specific patch to /usr/lib/rpm/elfdeps tool? -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Matwey V. Kornilov wrote:
However, internal dependency generator is enabled by default in rpm 4.10 and it seems to be powerful tool. Are there plans to adapt 'libwxfoo(variant)' syntax to IDG? Can find-wx-* stuff be implemented as suse specific patch to /usr/lib/rpm/elfdeps tool?
find-wx-* are working on top of the rpm dependency generator. It should do exactly the same as the internal dependency generator and only filters results. (If not, it is a bug.) There is a problem in the RPM shared library dependency generator: It works in an other way than the ld.so itself. It is not aware of differences between libraries in the ldpath (/etc/ld.so.conf* and LD_LIBRARY_PATH) and RPATH (libraries loaded via path specified in the binary/library). This causes more problems than only wx ABI clash. For example MozillaFirefox has a custom dependency generator for the same reason. I guess it does not make sense to introduce SUSE specific multi-ABI WX patch to RPM. But it would be welcome, if somebody would implement support for RPATH library dependencies: Requires: - libraries found in RPATH would add the RPATH to the rpm symbol. - libraries found in the ldpath would work as it do now Provides: - libraries installed outside the current ldpath would add its path to the rpm symbol. - libraries installed somewhere in the current ldpath would work as they work now -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
2013/3/29 Stanislav Brabec <sbrabec@suse.cz>
find-wx-* are working on top of the rpm dependency generator. It should do exactly the same as the internal dependency generator and only filters results. (If not, it is a bug.)
It looks like it doesn't do that. When %_use_internal_dependency_generator is defined to zero, stuff located in /usr/lib/rpm/fileattrs/*.attr isn't taken into account at all. (at least, for 12.3) Hm, I have to dig deeper. -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Matwey V. Kornilov wrote:
2013/3/29 Stanislav Brabec <sbrabec@suse.cz>
find-wx-* are working on top of the rpm dependency generator. It should do exactly the same as the internal dependency generator and only filters results. (If not, it is a bug.)
It looks like it doesn't do that. When %_use_internal_dependency_generator is defined to zero, stuff located in /usr/lib/rpm/fileattrs/*.attr isn't taken into account at all. (at least, for 12.3) Hm, I have to dig deeper.
Well, then the definition needs an update for the latest RPM. (And dependent packages would need a rebuild.) The result of WX dependency generator should be exactly the same for non-wx dependencies as the RPM generator. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stanislav Brabec wrote:
Matwey V. Kornilov wrote:
2013/3/29 Stanislav Brabec <sbrabec@suse.cz>
find-wx-* are working on top of the rpm dependency generator. It should do exactly the same as the internal dependency generator and only filters results. (If not, it is a bug.)
It looks like it doesn't do that. When %_use_internal_dependency_generator is defined to zero, stuff located in /usr/lib/rpm/fileattrs/*.attr isn't taken into account at all. (at least, for 12.3) Hm, I have to dig deeper.
Well, then the definition needs an update for the latest RPM. (And dependent packages would need a rebuild.)
The result of WX dependency generator should be exactly the same for non-wx dependencies as the RPM generator.
It seems, that things changed in RPM. In past, __find_provides did the same as the automatic requires/provides generator. Now, __find_provides uses the old hardcoded dependency generator, and internal dependency generator uses the new fileattrs way. Filtering the result of __find_provides was a way, how to edit automatic dependencies. I am not aware of any way, how to filter results of the internal dependency generator or call the internal one from the script. The internal generator is capable on adding new symbols, but it seems not being capable of removal symbols found by another module. So it would be probably good to implement generic ldpath filter to elf/elflib/elfdeps. It would make obsolete many symbol filters in spec files, but in case of wxWidgets it will probably break the current implementation. echo /usr/lib64/wx-2.8-wxcontainer/libwx_gtk2u_core-2.8.so.0 | ./elfdeps --assume-exec --provides would then detect that /usr/lib64/wx-2.8-wxcontainer is not in the ldpath, and not generate standard libwx_gtk2u_core-2.8.so.0()(64bit) but for example: libwx_gtk2u_core-2.8.so.0()(64bit)(/usr/lib64/wx-2.8-wxcontainer) So the rpm would know, that it does not fulfill libwx_gtk2u_core-2.8.so.0()(64bit). I will try to play with %__elflib_exclude_path or %_fileattrsdir as a temporary solution. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (2)
-
Matwey V. Kornilov -
Stanislav Brabec