Re: [PATCH] fix qemu building with older make

[Don Slutz <dslutz@verizon.com>]

On 07/30/14 05:22, Ian Campbell wrote:
> On Tue, 2014-07-29 at 17:13 +0100, 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]).
> (I've got a sense of Deja Vu, sorry if we've been through this
> before...)
>
> You aren't expected to support users installing Xen 4.5 onto SLE10
> though, surely? After general support and into long term support even?.
>
> For development purposes across multiple trees do chroot+bind mounts or
> VMs not suffice?
>
> I think our backstop for dependencies for the dom0 bits should be the
> version of things where we might reasonably expect a new user to deploy
> a new version of upstream Xen from scratch on. I find it hard to imagine
> anyone doing that on Debian 6.0, SLE10 or RHEL5 these days rather than
> choosing Debian 7.0, SLE11 or RHEL6.

RHEL6 is not directly usable as Dom0 for xen.  You have to add a different
kernel and so is more complex.  So to use only disto stuff you were limited
to RHEL5 :(. However RHEL7 should be usable without extra work (I have yet
to verify this is true, do to limited time).

    -Don Slutz

> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel