Stephen Gran wrote: > This one time, at band camp, Raphael Geissert said: >> More than one month ago I posted a list[1] of packages defining useless >> rpath's on amd64 based on an archive wide lintian check. > > [...] > >> If no one objects I'll start MBF within a week or, if encouraged to and >> with no objection, probably during the week. > > This one time, at band camp, Raphael Hertzog said: >> MBF is important when you plan to make an NMU campaign to correct all the >> packages... but just reporting the problem is useless because lintian >> does that very well already. And if lintian doesn't, then you can invest >> the time that you put in this MBF in a lintian patch. :-) > > I don't think I'm in favor of this particular issue, if only because > it's too much effort for too little gain. But it's important to > remember when raising the lintian objection that there are two problems > with it: not everyone builds on 64 bit arches (32 bit builds won't show > the problem, and lintian will stay quiet), and we don't seem to have (or > it isn't heavily advertised) a multi architecture aware lintian web site
As stated on my previous message the problem is often an outdated auto* file, a missing --opt or so. Not big deal but maintainers should be aware of the rpath issues. > (also, linitan.d.o seems down at the moment, but that's another issue). That's because lintian.d.o's lintian package was upgraded and the archive (i386+source) is being checked. > > If we had a place where maintainers could easily check the results of > lintian on platforms other than their own, I'd happily jump in and agree > that MBF's for lintian issues is mostly a waste of time. I've been looking forward using Mole for this but I didn't find its documentation very clear. But on the other hand there are some packages defining bad rpaths, an example is: W: kwave: binary-or-shlib-defines-rpath ./usr/share/apps/kwave/plugins/about /build/buildd/kwave-0.7.10/build/mt:/build/buildd/kwave-0.7.10/build/libgui:/build/buildd/kwave-0.7.10/build/libkwave This MBF would cover all of them. Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
