Anthony Liguori <anth...@codemonkey.ws> writes: > On 07/21/2010 04:58 PM, Daniel P. Berrange wrote: >>> Yes there is. Use the version number. >>> >> The version number is not suitable, because features can be removed at >> compile time and/or > > I don't see any features that libvirt would need to know about that > are disabled at compile time that aren't disabled by platform features > (i.e. being on a Linux vs. Windows host). > >> added via patch backports. > > If a distro backports a feature, it should change the QEMU version > string. If it doesn't, that's a distro problem. > >> The only reliable way is >> to query the QEMU binary to ask it what it actually supports. >> > > And you do that by asking QEMU what it's version number is. If the > version number isn't reliable because a distro backported features > without changing it, then the distro is broken. It's no different > than if we had a capabilities system and a distro added a feature > without adjusting the advertises capabilities.
No, because a version number isn't a capabilities system. With a capabilities system, a vendor can add vendor-specific capabilities. Should be necessary only as a last resort, because upstream already describes itself reasonably well, so most of the time you can just backport the upstream capability. With a version, all a vendor can do is graft their their own "capability system" into the version string, say encoded as vendor version. Guaranteed to be incompatible with anyone else's "capabilitity system". Only the vendor's tools will understand it, Which means users can't use anything else. Avoiding such vendor lock in is one of the core values of the free software world.
