[libvirt] libvirt.pc file
Why is libvirt.pc included in the tarball? It contains information learned at configure time, thus its contents depend on who built the tarball, which is in violation of the normal rule that any generated file that depends on config.status must not be shipped. Unless anyone has a good reason why it is distributed, I'm working on a patch to fix that. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
The rule of thumb is that any file generated by config.status is a) reproducible by any user, b) dependent on configure options. Therefore, it is inappropriate to include such generated files in the tarball (for proof, Makefile is generated from Makefile.in; the former is not in the tarball while the latter is). * Makefile.am (EXTRA_DIST): Remove files covered by AC_OUTPUT. --- Tested with 'make distcheck'. Makefile.am | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 0b4ae9d..ecc7435 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,9 +16,9 @@ XML_EXAMPLES = \ EXTRA_DIST = \ ChangeLog-old \ - libvirt.spec libvirt.spec.in \ + libvirt.spec.in \ mingw32-libvirt.spec.in \ - libvirt.pc libvirt.pc.in \ + libvirt.pc.in \ autobuild.sh \ Makefile.nonreentrant \ autogen.sh \ -- 1.7.4.4
On Fri, May 6, 2011 at 11:25 AM, Eric Blake <eblake@redhat.com> wrote:
The rule of thumb is that any file generated by config.status is a) reproducible by any user, b) dependent on configure options. Therefore, it is inappropriate to include such generated files in the tarball (for proof, Makefile is generated from Makefile.in; the former is not in the tarball while the latter is).
* Makefile.am (EXTRA_DIST): Remove files covered by AC_OUTPUT. ---
Tested with 'make distcheck'.
Makefile.am | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am index 0b4ae9d..ecc7435 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,9 +16,9 @@ XML_EXAMPLES = \
EXTRA_DIST = \ ChangeLog-old \ - libvirt.spec libvirt.spec.in \ + libvirt.spec.in \ mingw32-libvirt.spec.in \ - libvirt.pc libvirt.pc.in \ + libvirt.pc.in \ autobuild.sh \ Makefile.nonreentrant \ autogen.sh \ -- 1.7.4.4
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
ACK, this patch is correct to achieve the desired results. -- Doug Goldstein
On 05/06/2011 10:59 AM, Doug Goldstein wrote:
On Fri, May 6, 2011 at 11:25 AM, Eric Blake <eblake@redhat.com> wrote:
The rule of thumb is that any file generated by config.status is a) reproducible by any user, b) dependent on configure options. Therefore, it is inappropriate to include such generated files in the tarball (for proof, Makefile is generated from Makefile.in; the former is not in the tarball while the latter is).
* Makefile.am (EXTRA_DIST): Remove files covered by AC_OUTPUT. ---
Tested with 'make distcheck'.
ACK, this patch is correct to achieve the desired results.
Thanks; pushed. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, May 06, 2011 at 10:25:50AM -0600, Eric Blake wrote:
The rule of thumb is that any file generated by config.status is a) reproducible by any user, b) dependent on configure options. Therefore, it is inappropriate to include such generated files in the tarball (for proof, Makefile is generated from Makefile.in; the former is not in the tarball while the latter is).
[...]
diff --git a/Makefile.am b/Makefile.am index 0b4ae9d..ecc7435 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,9 +16,9 @@ XML_EXAMPLES = \
EXTRA_DIST = \ ChangeLog-old \ - libvirt.spec libvirt.spec.in \ + libvirt.spec.in \
Actually that part is wrong. The libvirt.spec need to be in the tarball to allow to build rpms from it. This breaks for example "make rpm". I reverted that part of the patch, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, May 9, 2011 at 1:32 AM, Daniel Veillard <veillard@redhat.com> wrote:
On Fri, May 06, 2011 at 10:25:50AM -0600, Eric Blake wrote:
The rule of thumb is that any file generated by config.status is a) reproducible by any user, b) dependent on configure options. Therefore, it is inappropriate to include such generated files in the tarball (for proof, Makefile is generated from Makefile.in; the former is not in the tarball while the latter is).
[...]
diff --git a/Makefile.am b/Makefile.am index 0b4ae9d..ecc7435 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,9 +16,9 @@ XML_EXAMPLES = \
EXTRA_DIST = \ ChangeLog-old \ - libvirt.spec libvirt.spec.in \ + libvirt.spec.in \
Actually that part is wrong. The libvirt.spec need to be in the tarball to allow to build rpms from it. This breaks for example "make rpm".
I reverted that part of the patch,
Daniel
Daniel, Since the Makefile doesn't ship in the tarball but only Makefile.in, which requires "./configure" be run before "make rpm" be run, that would mean that you don't need the libvirt.spec to be shipped in the tarball and you only want libvirt.spec.in and once you run ./configure it'll generate libvirt.spec. So in fact reverting that change is incorrect. Unless of course I'm missing something. -- Doug Goldstein
On 05/09/2011 08:45 AM, Doug Goldstein wrote:
EXTRA_DIST = \ ChangeLog-old \ - libvirt.spec libvirt.spec.in \ + libvirt.spec.in \
Actually that part is wrong. The libvirt.spec need to be in the tarball to allow to build rpms from it. This breaks for example "make rpm".
I reverted that part of the patch,
At least that's safe - libvirt.spec.in only substitutes @VERSION@, which is one of the few strings where ./configure settings won't affect what gets substituted. That is, libvirt.spec changes only when you change configure.ac to bump the version number, so it is safe enough to leave under version control as well as part of the tarball.
Since the Makefile doesn't ship in the tarball but only Makefile.in, which requires "./configure" be run before "make rpm" be run, that would mean that you don't need the libvirt.spec to be shipped in the tarball and you only want libvirt.spec.in and once you run ./configure it'll generate libvirt.spec. So in fact reverting that change is incorrect.
Unless of course I'm missing something.
You (and I) missed the fact that 'rpmbuild -ta libvirt-0.9.1.tar.gz' is able to build an rpm from the tarball, only if the tarball already contains a file named libvirt.spec. So Dan is right that libvirt.spec should belong to the tarball, even if it is generated by config.status. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Mon, May 09, 2011 at 09:45:49AM -0500, Doug Goldstein wrote:
On Mon, May 9, 2011 at 1:32 AM, Daniel Veillard <veillard@redhat.com> wrote:
On Fri, May 06, 2011 at 10:25:50AM -0600, Eric Blake wrote:
The rule of thumb is that any file generated by config.status is a) reproducible by any user, b) dependent on configure options. Therefore, it is inappropriate to include such generated files in the tarball (for proof, Makefile is generated from Makefile.in; the former is not in the tarball while the latter is).
[...]
diff --git a/Makefile.am b/Makefile.am index 0b4ae9d..ecc7435 100644 --- a/Makefile.am +++ b/Makefile.am @@ -16,9 +16,9 @@ XML_EXAMPLES = \
EXTRA_DIST = \ ChangeLog-old \ - libvirt.spec libvirt.spec.in \ + libvirt.spec.in \
Actually that part is wrong. The libvirt.spec need to be in the tarball to allow to build rpms from it. This breaks for example "make rpm".
I reverted that part of the patch,
Daniel
Daniel,
Since the Makefile doesn't ship in the tarball but only Makefile.in, which requires "./configure" be run before "make rpm" be run, that would mean that you don't need the libvirt.spec to be shipped in the tarball and you only want libvirt.spec.in and once you run ./configure it'll generate libvirt.spec. So in fact reverting that change is incorrect.
Unless of course I'm missing something.
When running: rpmbuild --ta libvirt-0.9.1.tar.gz it will look for 'libvirt.spec' inside the tar.gz, therefore we *must* include it in EXTRA_DIST & the revert was correct. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, May 09, 2011 at 09:45:49AM -0500, Doug Goldstein wrote:
On Mon, May 9, 2011 at 1:32 AM, Daniel Veillard <veillard@redhat.com> wrote: Since the Makefile doesn't ship in the tarball but only Makefile.in, which requires "./configure" be run before "make rpm" be run, that would mean that you don't need the libvirt.spec to be shipped in the tarball and you only want libvirt.spec.in and once you run ./configure it'll generate libvirt.spec. So in fact reverting that change is incorrect.
Unless of course I'm missing something.
I guess you are missing the fact that rpm can work out of a (compressed) tarball, run "rpm -ta foo.tar.gz" and it will extract a .spec from it and use this to then build all the rpms out (assuming you don't need patches from the spec file). Very convenient and what "make rpm" does. You need to run autogen on a checkout for this. But you can run it directly from any of the libvirt-xxx.tar.gz that end up as release or provided hourly as git snapshots. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Doug Goldstein -
Eric Blake