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