Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.02.16 at 16:46, <mcgrof@xxxxxxxx> wrote:
> On Tue, Feb 09, 2016 at 03:54:05AM -0700, Jan Beulich wrote:
>> >>> On 06.02.16 at 05:03, <mcgrof@xxxxxxxx> wrote:
>> > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> >> Also - how does this work if you have an older version of SuSE,
>> >> say SLES10?
>> > 
>> > Beats me. I just dealt with getting this to compile with what is current.
>> > I kind of doubt what is in xen master or staging will end up in SLE10's
>> > version of Xen too. If that had to happen people porting this to an old
>> > library could just add a helper gnutls_priority_set_direct() wrapper to
>> > do things the old way.
>> 
>> Looks like you misunderstand: The question isn't what products
>> code might end up in, but what platforms are supported for
>> building. Right now, building of Xen and tools still works on SLE10
>> (and e.g. gcc is documented to be usable far enough back), so
>> you should avoid breaking the build on such older platforms (or
>> if you can't avoid it, you should make this explicit).
> 
> I did misunderstand the question, but the same question applies, are
> we supposed to backport solutions for new libraries all the way down to
> things such as SLE10? That's a pretty important requirements and it
> by no means was clear as a requirement to me. Is full Xen compiling
> on SLE10 as of today before these changes? Who's testing that? Why
> SLE10 and not factory?

The requirement is not SLE10 in particular (just that it serves as a
good example), but "older distros" more generally, i.e. would as
well apply to the equivalent RHEL. For support reasons I have two
such systems left, and I do build and run Xen on them on a regular
but not very frequent basis (about once every two to three months).

Jan


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