Kevin Kofler writes:
Sam Varshavchik wrote:Now, why don't you explain why, and we'll go from there. Presuming that this is needed because some script in $srcdir uses the PERL environment variable, or a later part of the configure script itself (it assumes that PERL is set in the environment) then I would just patch in: PERL=/usr/bin/perl export PERL instead, to configure.This is a really dirty hack and cannot be upstreamed.
I see. A surgical patch that addresses the build failure directly is dirty. It's much cleaner to patch a different file that's one step removed, then run a tool to regenerate the script where the original problem was, and hope that there are not going to be any side effects.
And I don't recall ever claiming that this should be sent directly upstream. Upstrem can be informed in parallel, so that the proper fix can be put in place.
Fixing configure.ac is
the clean fix.
Fixing configure.ac accomplishes absolutely nothing. One has to run autotools to propagate the fix, and that's the messy part. Like I said, due diligence would require you to track which specific version of autotools the upstream used to generate the original scripts, and whether or not there's any code in configure.ac that's specific to that version of autotools, so that any side effects can be properly vetted, when the entire build system gets regenerated by autotools.
That "meme" goes around for a reason, patching a generated file is dirty,
From the viewpoint of a package builder it is not a generated file. It comes
right out of the tarball, as is.
can be hard to do depending on what you want to patch, leads to patches which can't be upstreamed and, if the source code is GPLed, violates the GPL.
How exactly would that violate the GPL?
Attachment:
pgpB32Ujy1pIx.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
