Bug#579025: libflac-dev: libFLAC.m4 may set empty -L flag

[Thibaut VARENE]

On Tue, Jun 15, 2010 at 11:44 AM, Fabian Greffrath <fabian at greffrath.com> wrote:
> forwarded 579025 https://sourceforge.net/tracker/?func=detail&atid=113478&aid=3016381&group_id=13478
> severity 579025 normal
> thanks
>
> I have forwarded your bug report to upstream's bug tracker at
> sourceforge. I think this is an upstream bug and it should get fixed
> upstream.
>
> Fixing it in Debian would mean an undesirable deviation from upstream
> and force the sourceful uploads of 43 packages, including
> re-autoconf'ing. I don't think it's worth the effort, since currently no
> single package in Debian is actually affected by this bug (the default
> prefix for autotools is /usr/local, so every package in Debian needs to
> run configure with at least --prefix=/usr, which hides the bug) and the
> workaround is quite simple (e.g. run configure with --prefix=/usr/local,
> which is the default anyway). Hope you agree!

I agree with your reasoning from Debian's PoV. Now, I would really
like to see this bug fixed before Squeeze is released, because I do
not agree with how you seem to underestimate how important this bug is
for people releasing source package using libFLAC.m4. I now have to
make sure that the machine I'm generating my source package on has a
properly patched libFLAC.m4. Of course, any update of libflac-dev will
overwrite the patch, adding to the burden.

This bug was first reported to me by people running the (very common)
"./configure && make && make install" on my package, and experiencing
FTBFS on it because it was generated against buggy libFLAC.m4. It took
me quite a while to figure what was going on (and I humbly believe
that I'm more experienced than the average user of my package), thus I
think you cannot expect average people who barely know how to build a
package to "guess" that when they see such a cryptic error as
"libtool: link: require no space between `-L' and `-lFLAC'"; that they
should pass --prefix=/usr/local to fix it... I hope you agree with me
;-P

Could you consider, as a mitigation between two extreme options, that
in the event upstream fails to fix this bug in a timely fashion,
whenever you upload a new version of libflac you'd include this patch
with it? It can easily be reverted to whatever upstream finds sensible
afterwards, and will at least ensure that newer versions of libflac
aren't plagued with this bug. Since Debian is unaffected per se, the
sourceful rebuild of affected packages is not necessarily mandatory,
but there again, it would ensure that newer packages aren't affected
anymore... Does that make sense?

Thanks

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/