Re: [Libguestfs] Perl module versioning
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