[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]