[libvirt] [PATCH] Don't ship autogen.sh in release tarballs
autogen.sh is only useful for developers, not users, and we expect developers to have a git checkout handy, so there's no point in shipping the script in release tarballs. autobuild.sh uses autogen.sh, so don't ship that either. --- Makefile.am | 2 -- 1 file changed, 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index c6324f5..0efd8be 100644 --- a/Makefile.am +++ b/Makefile.am @@ -36,9 +36,7 @@ EXTRA_DIST = \ libvirt-qemu.pc.in \ libvirt-lxc.pc.in \ libvirt-admin.pc.in \ - autobuild.sh \ Makefile.nonreentrant \ - autogen.sh \ cfg.mk \ run.in \ AUTHORS.in -- 2.7.4
On 04/13/2017 10:06 AM, Andrea Bolognani wrote:
autogen.sh is only useful for developers, not users, and we expect developers to have a git checkout handy, so there's no point in shipping the script in release tarballs.
I'm worried this breaks the GPL. autogen.sh is our preferred way for rebuilding autotools in preparation for a release, and thus I think the script belongs in a tarball even if it is not expected to be used by the end user.
autobuild.sh uses autogen.sh, so don't ship that either. --- Makefile.am | 2 -- 1 file changed, 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am index c6324f5..0efd8be 100644 --- a/Makefile.am +++ b/Makefile.am @@ -36,9 +36,7 @@ EXTRA_DIST = \ libvirt-qemu.pc.in \ libvirt-lxc.pc.in \ libvirt-admin.pc.in \ - autobuild.sh \ Makefile.nonreentrant \ - autogen.sh \ cfg.mk \ run.in \ AUTHORS.in
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Thu, Apr 13, 2017 at 10:11:50AM -0500, Eric Blake wrote:
On 04/13/2017 10:06 AM, Andrea Bolognani wrote:
autogen.sh is only useful for developers, not users, and we expect developers to have a git checkout handy, so there's no point in shipping the script in release tarballs.
I'm worried this breaks the GPL. autogen.sh is our preferred way for rebuilding autotools in preparation for a release, and thus I think the script belongs in a tarball even if it is not expected to be used by the end user.
Aside from the licensing question, IMHO, the tar.xz should always contain all the files we have in GIT, plus whatever auto-generated files we decide are needed. If nothing else that gives users clear visibility into what generated the auto-generated files, even if they don't need to re-run that auto-generation process themselves. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On 04/13/2017 10:19 AM, Daniel P. Berrange wrote:
On Thu, Apr 13, 2017 at 10:11:50AM -0500, Eric Blake wrote:
On 04/13/2017 10:06 AM, Andrea Bolognani wrote:
autogen.sh is only useful for developers, not users, and we expect developers to have a git checkout handy, so there's no point in shipping the script in release tarballs.
I'm worried this breaks the GPL. autogen.sh is our preferred way for rebuilding autotools in preparation for a release, and thus I think the script belongs in a tarball even if it is not expected to be used by the end user.
Aside from the licensing question, IMHO, the tar.xz should always contain all the files we have in GIT, plus whatever auto-generated files we decide are needed. If nothing else that gives users clear visibility into what generated the auto-generated files, even if they don't need to re-run that auto-generation process themselves.
As another data point, recent coreutils has moved towards the tarball only having recent changes, plus documentation about how to find the source repository for older changelogs, storing the older changes only in the source repository. But again, licensing wise, the changelogs are NOT the preferred source form for creating a tarball, while the bootstrap and autogen.sh scripts ARE, so there's a big difference between trimming tarball size by dropping build scripts vs. trimming tarball size by dropping data that is not a build impact. You have to have a really strong reason for making a tarball that is not a superset of a git checkout, as it gets very hard to prove that the tarball is then sufficient to create a fork (and the fact remains that the GPL requires anyone getting a libvirt binary be afforded the chance to fork from the same sources used to build that binary). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Thu, 2017-04-13 at 10:28 -0500, Eric Blake wrote:
On 04/13/2017 10:19 AM, Daniel P. Berrange wrote:
Aside from the licensing question, IMHO, the tar.xz should always contain all the files we have in GIT,
Including .gitignore? ;) [...]
You have to have a really strong reason for making a tarball that is not a superset of a git checkout, as it gets very hard to prove that the tarball is then sufficient to create a fork (and the fact remains that the GPL requires anyone getting a libvirt binary be afforded the chance to fork from the same sources used to build that binary).
I hadn't thought about the potential legal consequences: let's just stay on the safe side and leave the file in. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel P. Berrange -
Eric Blake