[Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide

[Daniel P. Berrange]

On Mon, Sep 08, 2008 at 03:26:23PM +0200, Jim Meyering wrote:
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> > On Mon, Sep 08, 2008 at 02:32:03PM +0200, Jim Meyering wrote:
> >> --- a/ovirt-identify-node/Makefile
> >> +++ b/Makefile.am
> ...
> >> +include release.mk
> >>
> >> -clean:
> >> -	rm -rf $(OBJECTS) $(TARGET)
> >> -
> >> -$(TARGET): $(OBJECTS)
> >> -	$(CC) -o $@ $(OBJECTS) $(LFLAGS)
> >> -
> >> -.PHONY: all clean
> >> +pkg_name = ovirt-node
> >> +.PHONY: tar
> >> +tar: dist
> >> +	tar xf $(distdir).tar.gz
> >> +	mkdir -p rpm-build/BUILDROOT
> >> +	tar zcvf rpm-build/$(NV).tar.gz $(NV)
> >> +	cp version rpm-build
> >> +	chmod -R u+rwx $(NV)
> >> +	rm -rf $(NV)
> >
> > Do we really need to preserve this custom target  when automake
> > provides a perfectly good 'make dist'. It just seems to be taking
> > the tar.gz, extracting it, and then re-creating it with files having
> > a rpm-build/  prefix which is just wierd. RPMs should be built from
> > the real tar.gz automake provides.
> 
> Not really, but since other things (see 5 other copies of included
> release.mk) currently rely on that layout, this keeps my changes
> small and relatively safe.

Hmm, actually this is even more bizarre that I thought - it isn't
actually creating the tar.gz with different prefix. Unless I'm
missing something, can't it be simplified to

> >> +tar: dist
> >> +  cp $(distdir).tar.gz rpm-build/
> >> +  cp version rpm-build

Ultimately 'release.mk'; should just call 'make dist' and look
in the top level dir to start with, but good idea to separate
that change from the main re-factoring.

> >> +
> >> +# for ovirt-identify-node
> >> +PKG_CHECK_MODULES([DBUS], [dbus-1])
> >> +PKG_CHECK_MODULES([HAL], [hal])
> >> +PKG_CHECK_MODULES([VIRT], [libvirt])
> >
> > Should check for minimum required versions really - I'm sure there's
> > a minimal libvirt you need. If you don't know what version of DBus
> > or HAL is required, then pick one from F9 and we can tweak it later
> >
> > eg,
> >
> >   PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4])
> 
> Thanks, but how about feature checks instead of version checks?
> IME, they're less work in the long run, assuming you can come
> up with a good witness to the desired feature.  I.e., if some
> function was added for libvirt-0.4.4, a simple check for its
> existence in libvirt.
> 
> I hesitated to use PKG_CHECK_MODULES, because of the grief
> it's given me in other projects ;-), but in an attempt to keep
> this change quick, small and simple I used it nonetheless.
> Well, in keeping with KISS, I'll take your advice after all.

The trouble with checking for desired features, is which function
do you check for as your 'base' level check. The idea of feature
checks it to let someone backport a feature  and not get tripped
up by a version check, but there's still some level of basic
functiuonality required. 

For GTK-VNC I make use of both approaches. A basic check for a
reasonable known minimum version, and then feature checks for
specific addons from newer versions we're able to work work

GTK_REQUIRED=2.10.0
PKG_CHECK_MODULES(GTK, gtk+-2.0 >= $GTK_REQUIRED)
AC_CHECK_LIB([gdk], [gdk_cairo_create], [WITH_GTK_CAIRO=1], [WITH_GTK_CAIRO=0])


> Here's the incremental change:

ACK

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|