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

Re: [Libguestfs] Perl module versioning

On 08/09/09 11:39, Richard W.M. Jones wrote:
   Perl modules are unversioned, but should carry version numbers

Currently perl RPM deps are unversioned.  Apparently if we add a
version number into the perl module(s) then we can fix that, eg:

   our $VERSION = "1.0.68";

This would allow Perl users to specify the version either through an
RPM dependency or in code like this:

   use Sys::Guestfs 1.0.68;

The file in question (perl/lib/Sys/Guestfs.pm) is generated.  Up to
this point I have resisted putting the version number into any
generated files.  One reason is that it's unnecessary churn for those
files.  Another is that we shouldn't encourage users to depend on
specific versions (instead, they should test for required features).
Another is that the version of Sys::Guestfs doesn't really tell you
what is available in the dynamically-loaded libguestfs.so, nor in the

Worked example:

Your program needs $g->zerofree.

(1) May or may not exist in the Perl library.

(2) May or may not exist in the C API (libguestfs.so).

(3) May or may not exist in the daemon (stubs.c:zerofree_stub)

(4) May or may not have been added to the appliance (/usr/bin/zerofree)

Since so much can potentially go wrong, I think the only realistic
solution is along these lines:

   eval { $g->zerofree(...) }; die "zerofree failed: $@" if $@;

Do other languages offer equivalent runtime detection?  [OCaml - no]

How do we ensure in RPM/dpkg that a consistent set of packages are
installed?  RPM only "knows" version numbers, unless we export lots of
fine-grained dependencies.  So far the solution has been to depend on
the C library, like:

   Requires: libguestfs>= 1.0.68


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.

2. While a version number doesn't guarantee the presence of a feature, it can guarantee the absence of a feature. 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.

Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

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