Re: Non-source Javascript files in upstream source
On Fri, May 02, 2014 at 09:20:02PM +0200, Bas Wijnen wrote:
>
> 1. Do we need to check that generated files which we don't use are actually
> generated from the provided source? Main example here is a configure file
> which gets overwritten during build.
For the record, the reason why I ship a configure as well as a
configure.in file with e2fsprogs is simply because I don't trust that
an arbitrary version of autoconf won't break with what I have in my
configure.in. And I don't want to trouble-shoot some random Gentoo's
user's version of autoconf --- as far as I am concerned, the autoconf
maintainers have provided no guarantees of stability between versions,
at least none that I am willing to trust.
So I am only going to ship configure as generated by a version of
autoconf that I have personally tested as working. And there have
been times in the past when I've simply kept an older version of
autoconf because the current version of autoconf was busted as far as
I was concerned, and I didn't have time to trouble shoot the damned
thing.
If someone starts complaining that I shipped a version of configure
that corresponded to autoconf version N, and sid just uploaded N+1,
and therefore my configure doesn't match with my configure.in, and
that's therefore a DFSG violation, I'm going to be really annoyed.
Heck, when autoconf has been busted, there have been times that
modifying the configure script directly *was* my preferred form for
making modifications....
*Especially* if debian stable, testing, unstable, and experimental
might theoretically have completely different versions of autoconf,
making it fundamentally impossible to guarantee that configure is
"exactly generated" from the version of autoconf in all releases of
Debian.
There is such a thing of trying to adhere to the DFSG to the point of insanity....
- Ted
Reply to: