From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] fix qemu building with older make Date: Tue, 29 Jul 2014 17:27:08 +0100 Message-ID: <53D7CB5C.4000107@citrix.com> References: <53D6332002000078000267C3@mail.emea.novell.com> <21463.43107.996862.418550@mariner.uk.xensource.com> <53D7CA430200007800027501@mail.emea.novell.com> <21463.49467.652734.346861@mariner.uk.xensource.com> <53D7E4320200007800027623@mail.emea.novell.com> <53D7C9CC.2010707@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XCAFo-0001pT-CB for xen-devel@lists.xenproject.org; Tue, 29 Jul 2014 16:27:56 +0000 In-Reply-To: <53D7C9CC.2010707@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Jan Beulich , Ian Jackson Cc: Ian Campbell , xen-devel , Keir Fraser , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 29/07/14 17:20, George Dunlap wrote: > On 07/29/2014 05:13 PM, Jan Beulich wrote: >>>>> On 29.07.14 at 17:43, wrote: >>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"): >>>> On 29.07.14 at 15:57, wrote: >>>>> (b) have some kind of >>>>> time limit on how long we need to support make 3.80 ? >>>>> >>>>> 3.81 was released upstream over eight years ago in April 2006. >>>> >>>> I know, but I also know there's going to be a few more years where >>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest >>>> common denominator in order to be able to test backports there. >>>> And RHEL5, iirc released at about the same time, was also quite >>>> recently considered a platform desirable to continue to support. >>> >>> RHEL5 was released in March 2007, 11 months after make 3.81 was >>> released upstream. Furthermore it is seven years old. SLES10 was >>> released in June 2006, and is therefore eight years old. People refer >>> to Debian stable as `Debian stale' but frankly this is ridiculous. >>> >>> At the very least can we put some kind of bound on this ? >>> >>> How about we `compromise' on the following rule: we will feel >>> completely entitled to delete any build and tools compatibility code >>> for anything which was superseded upstream more than a decade ago. >> >> I'm personally not in favor of this, but if a reasonably large majority >> would want a rule like this, I'll have to try and live with it. My scope >> for deprecation would be more towards such relatively wide spread >> distros going completely out of service (i.e. in the case of SLES not >> just general support [which happened about a year ago], but also >> long-term/extended support [which I think is scheduled for like 12 >> or 13 years after general availability]). > > FWIW, one of the things that has made Docker possible is Linus' > quixotic commitment to binary compatibility for any user-space > program, whether in a distro or not. > > RHEL apparently has several lifecycle "phases" > (https://access.redhat.com/support/policy/updates/errata/); > "Production 2" for RHEL 5 just ended in January of this year; > "Production 3" won't end until 2017, and the "Extended Life Phase" > won't end until 2020. > > Staying compatible with major distros, particularly if it's something > small (if slightly ugly) like this, seems like a small price to pay. > > -George We should not aim to deliberately break things. I would suggest a slightly more lax approach; if the distro has a requisite version in a standard package repository then we could consider breaking compatibility with the older package version. e.g. a newer version of make available in something like EPEL for RHEL5. I have no knowledge of whether such things exist for SLES. ~Andrew