On Tue, Sep 08, 2009 at 12:37:40PM +0100, Matthew Booth wrote:
I agree that feature tests are required in code. However, I think there are other things to consider:
1. The above argument only applies to the libguestfs API and its language bindings. This doesn't quite cover everything e.g. Sys::Guestfs::Lib.
The problem was that Sys::Guestfs::Lib was missing some static function (inspect_linux_kernel IIRC). This is not a generated file, so there is no immediate problem with adding a version number. If we want to add the libguestfs version number, then we have to make this file into an autoconf *.in file. This is not a big problem.
2. While a version number doesn't guarantee the presence of a feature, it can guarantee the absence of a feature.
I think you may mean this the other way around ...
So it's still meaningful to say that my program requires version x.y.z, although it may also require other things.
3. When faced with a program not working because feature X is absent, it would be help to know if you need to upgrade to a new libguestfs, or fix the one you've got.
Yeah, I think the RPM dependency issue is a strong point. We must avoid installing sets of RPMs which fail. The alternative to version numbers is some sort of fine-grained dependency: Provides: perl(Sys::Guestfs::Lib::inspect_linux_kernel) but that's a lot of work. So I think adding a version number to Sys::Guestfs::Lib (which is not generated) should help, but not to Sys::Guestfs. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora