[libvirt] Enable kvm on aarch64, Cleanup F-16/18 conditionals
eblake at redhat.com
Tue Jul 15 22:15:50 UTC 2014
On 07/15/2014 04:00 PM, Peter Robinson wrote:
[reformatting to avoid top-posting]
> On Tue, Jul 15, 2014 at 6:52 PM, Daniel P. Berrange
<berrange at redhat.com> wrote:
>> Historically we've kept support for building libvirt against
>> Fedora versions even if unsupported by Fedora itself, because
>> we've found people often stick on old Fedora versions. At some
>> point though it does get a bit insane. eg we don't really need
>> Fedora 8 support at this point. If we are going todo a cleanup
>> though, we should do it throughout the spec, not just in these
>> few places
> Sorry, I missed the Fedora 8 stuff. Would it even work on Fedora 8
> with all the various other changes? Not sure it's worth the effort for
> the few people that want that release as a hypervisor, I can
> understand for the supported elX releases but not sure the Fedora
> releases that are systemd based give value to elX releases and are
> generally relatively ancient history. Dan do you really have know
> users of the latest release running it on F-8?
> In terms of pushing upstream Cole has said he's happy to push the
> commits to ensure it fits your work flows.
Doing an out-of-the-box build on RHEL 5 is the oldest configuration
still actively (if marginally) supported, ideally for as long as RHEL 5
remains a live platform (several more years to go). We have build-bots
that ensure that we can build on RHEL 5, although I'm not sure if those
buildbots are exercising 'make rpm' to test the older parts of the spec
file. Historically, RHEL 5.10 is based off of libvirt-0.8.2, and that
was the release in use during Fedora 13. So it's _definitely_ worth
culling any conditionals older than F13; but stuff between F13 and F18
might be shared with RHEL 5, and therefore more effort to cull the
Fedora side while still leaving the RHEL side intact.
I could go either way if we were to set some sort of policy (maybe: any
fedora release that is unsupported for more than a year is no longer
required to be supported in the spec file), and use that to justify
cleanups of older parts of the spec file as long as it doesn't break
RHEL 5. F16 is definitely more than a year out-of-date, F18 is a bit
more borderline on whether we are ready to call it unsupported.
Anyone else on the libvirt list have an opinion on how far back we can
clean without annoying people that are slow on the upgrade to modern Fedora?
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 604 bytes
Desc: OpenPGP digital signature
More information about the libvir-list