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(a)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