Re: Proposed MBF: packages defining useless RPATH's
Raphael Hertzog wrote:
> On Mon, 18 Feb 2008, Raphael Geissert wrote:
>> Besides of what Stephen Gran already said on his message I believe
>> there's no chance of NMU's to take place if the bugs aren't reported :).
>
> I would never NMU just to correct an harmless rpath. Thus if I NMU such a
> package, it's because of something else and I usually try to fix easy
> lintian warning/errors at the same time.
But if a package has a lot of not-so-important bug reports they could be
fixed in a NMU.
If there aren't, the maintainer could simply take care of fixing them in the
next upload, just like with all those not working watch files.
>
> I'm not even sure I would bother fixing this particular issue because
> updating autotools stuff is never without risks. Maybe I might add a
> chrpath -d but that's not the elegant solution.
That's a general statement that doesn't necessarily cover all the different
situations. The maintainer should find a way to fix the problem.
>
> I still think it's not a very good idea. I agree with Stephen's
> concerns but that should motivate you to fix lintian's shortcomings not
> to continue this MBF.
Well, I do believe it is a good idea to MBF mainly because people is usually
unaware of those problems and clearly not everybody checks lintian.d.o but
just run lintian on their .changes before uploading. And as stated several
times, the 'problem' is that on i386 and other architectures the rpath
issues don't show up.
Also, six weeks ago I already posted a list of the affected packages and it
is clearly visible that not many people are taking care of fixing them.
By the way, quoting Russ Allbery (<87d4scw17a.fsf@windlord.stanford.edu>):
> It already takes over a day for Lintian to process the entire archive, so
> I don't have any immediate plans to run it on more architectures unless we
> can find some dramatic way to speed it up or find other places to run it
> besides gluck.d.o.
>
> One guess as to the speed hit at the moment is the man page checks, since
> running man and groff is noticably slow.
The rest of that thread[1] only state some ideas but nothing that is very
likely to happen anytime soon.
[1]http://thread.gmane.org/gmane.linux.debian.devel.general/123165/
I hope this MBF proposal is reconsidered.
>
> Cheers,
Cheers,
Raphael Geissert
Reply to: