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. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v