Re: [PATCH] fix qemu building with older make

[George Dunlap <george.dunlap@eu.citrix.com>]

On 07/31/2014 01:00 PM, Don Slutz wrote:
>
> 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).

Eh?  It was my understanding that in RHEL7 they'd taken out *all* the 
pvops stuff, even what is required for the RHEL7 kernel to run as a 
plain PV domU, much less what is required for dom0.  (It still has the 
stuff necessary for PVHVM mode, AFAIK.)

  -George