On Tue, 20 Nov 2007, Aurelien Jarno wrote: > > Though it's worth asking ourselves if it would make sense to have an > > intermediary fallback between debian/*.symbols.<arch> and debian/*.symbols > > that > > would be debian/*.symbols.<kernel>. > > While it will fixes the problem due to the variation of the ABI across > kernels, I am not sure that is the problem we will see the most. The > most problematic variations, will happens on the same kernel, as it > could be seen from bugs #441736, #429600 or #342084.
Riku said in #441736: "This is the same bug as on unixodbc, #429600, #342084." The issue is that some supplementary symbols are exported due to libtool working differently with C++ libs for apparently no good reasons. It is not really armel-specific (except for the fact that armel generated supplementary symbols that should be not exported according to the version script). In any case, having new symbols as is the case in those reports will not generate a failure with the default behaviour of dpkg-gensymbols unless the maintainer want those failures. So it's still not representative of failures that we're likely to get due to dpkg-gensymbols (unless many maintainers decide to increase the level of checks, which I doubt. Furthermore maintainers that do that are likely reactive maintainer that will quickly integrate changes needed for unofficial architectures). That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
