Re: Proposed MBF: packages defining useless RPATH's
Stephen Gran wrote:
> This one time, at band camp, Raphael Geissert said:
>> More than one month ago I posted a list 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
W: kwave: binary-or-shlib-defines-rpath ./usr/share/apps/kwave/plugins/about
This MBF would cover all of them.