Matthias Clasen <mclasen@redhat.com> writes:
> On Mon, 2008-05-05 at 18:22 +0200, Ralf Corsepius wrote:
>> The key to avoid autotool compatibility issues is simple: Do not
>> generate autotool generated files while building.
>> Generate them off-line.

> ...which won't be easy if the autotool versions you need to generate
> them are kicked out.

Yeah. We have a rule against shipping binary blobs. A binary blob can
fairly be defined as a derived file that you lack the source to, or lack
the tools to get from the source to the derived file. How is it
different if we ship an autotools-derived file that the recipient
cannot regenerate from source? Smells like a GPL violation to me.

regards, tom lane

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Tom Lane wrote:

Matthias Clasen <mclasen@redhat.com> writes:

On Mon, 2008-05-05 at 18:22 +0200, Ralf Corsepius wrote:

The key to avoid autotool compatibility issues is simple: Do not
generate autotool generated files while building.
Generate them off-line.



...which won't be easy if the autotool versions you need to generate
them are kicked out.


Yeah. We have a rule against shipping binary blobs. A binary blob can
fairly be defined as a derived file that you lack the source to, or lack
the tools to get from the source to the derived file. How is it
different if we ship an autotools-derived file that the recipient
cannot regenerate from source? Smells like a GPL violation to me.

The idea is to ship both the patch for configure.ac/Makefile.am which
can go upstream and the diff between the old version of the generated
configure/Makefile/Makefile.in's and the new. So source is being provided.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list