Raphael Hertzog a écrit : > 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).
You can get data for kfreebsd-i386, kfreebsd-amd64 and armel from gnuab.org. The repository is rsyncable, and we can even send a push signal. But that don't solve the problem for other unofficial architectures (what comes to mind is nexenta, sh4, m32r). >>> 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. You are changing the truth. I never said "we shouldn't do anything", I proposed solutions so that the packages do not FTBFS on unofficial architectures. But you rejecting most them, instead trying to convince me there is no or very few problems. Also note that the main difference is that FTBFS are considered RC for official architectures, so if a maintainer don't do his/her job, others can NMU the package. That is not true for unofficial architecture, even if we managed to NMU some of them when the maintainer is clearly MIA. >>>>> 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, -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
