10:06 a.m.
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
10:11 a.m.
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
10:19 a.m.
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/ :|
10:28 a.m.
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
11:43 a.m.
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
2817
days inactive
2817
days old
4 comments
3 participants
participants (3)
-
Andrea Bolognani -
Daniel P. Berrange -
Eric Blake