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@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