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
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
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
On 08/09/09 15:20, Richard W.M. Jones wrote:
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 ...
No, it was just a slightly obtuse phrasing ;) An old version number can guarantee the absence of a feature. i.e. it can be guaranteed to be definitely too old.
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.
Yeah, that's definitely not worth it.
So I think adding a version number to Sys::Guestfs::Lib (which is not generated) should help, but not to Sys::Guestfs.
I would also add a version to Sys::Guestfs. As you point out, this isn't enough to guarantee that it will work, but it can exclude a large class of cases which definitely won't work. It will also give a much more useful error in this case. In practise, given that distributors are unlikely to package libguestfs without all the features enabled, I would expect it to exclude *all* cases which don't work. 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
participants (2)
-
Matthew Booth -
Richard W.M. Jones