[Libguestfs] Perl module versioning

Matthew Booth mbooth at redhat.com
Tue Sep 8 11:37:40 UTC 2009


On 08/09/09 11:39, Richard W.M. Jones wrote:
> Re:
>    https://bugzilla.redhat.com/show_bug.cgi?id=521674
>    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
> daemon/appliance.
>
> 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
>
> Rich.
>

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.

Matt
-- 
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




More information about the Libguestfs mailing list