Re: [PATCH] fix qemu building with older make

[Andrew Cooper <andrew.cooper3@citrix.com>]

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, <Ian.Jackson@eu.citrix.com> wrote:
>>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> 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