On Tue, 20 Nov 2007, Aurelien Jarno wrote: > >> Please read the bug log again. The supplementary symbols are not the > >> same on the different architectures, which causes some architectures to > >> have missing symbols compared to some others. > > > > In which case it doesn't make sense to have a common symbols file and the > > problem is solved. > > Except that the problem appearing only on unofficial architectures, mole > provide a common symbols file. That is where the problem lies.
If we manage to have common symbol set for hurd-i386 and all the other arches, then I think it should be doable to have the same symbol set on unofficial architectures (or at least a superset). > > So the initial problem is not armel-specific and I fail to see why > > we should ignore it when this failure enabled us to discover a bug in > > libtool. > > Even if the bug is present in all architectures, its effects are only > visible on armel. And maintainers do not care about unofficial > architectures, so the package will simply FTBFS. The fix is to remove one private symbol from the debian/*.symbols file so that the lack of the symbol doesn't generate a failure. This fix is trivial and can be done easily in a porter NMU without risking to break everything. > libtool is buggy, and that is even more true for older versions. And if > you look at the archive, you will see that most of libraries use an old > libtool version. Indeed, but maybe the implementation of proper symbols versioning in the debian package will trigger the required relibtoolizing... because hurd-i386 also needs it in many cases. > The library has to fixed, but the job of porters is not to fix general > problems with libraries, we already have a lot of work to do in other > domains. But if porters doesn't fix this, the maintainer will simply > ignore the problem, even if a bug report is sent. If we follow your logic, we shouldn't do anything because maintainers are not doing their work. While there's some truth in that, I just can't accept this conclusion. > >>> 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. > >> That is not a correct solution. If you are able to list private symbols, > >> better not export them instead of flagging them. > > > > Yes, but that's not something I control. In fact, if that's what you want, > > it's better to fail so that we can report problems to maintainers who will > > then prod upstream to implement a version script or similar. > > I totally agree it's better to fail in such cases, but it is better to > fails on all architectures, so that the problem is not just ignored. If only... there's no way for me to know if a symbol was intendend to be private or not. So I can't do this. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
