On Tue, Jun 15, 2010 at 11:44 AM, Fabian Greffrath <fab...@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/ _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
