qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>, "John Snow" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] Deprecation policy and build dependencies
Date: Wed, 5 Jun 2019 16:44:03 +0100	[thread overview]
Message-ID: <20190605154403.GH8956@redhat.com> (raw)
In-Reply-To: <20190531192429.GH22103@habkost.net>

On Fri, May 31, 2019 at 04:24:29PM -0300, Eduardo Habkost wrote:
> Long story short: I would really like to drop support for Python
> 2 in QEMU 4.1.
> 
> What exactly prevents us from doing this?  Does our deprecation
> policy really apply to build dependencies?

In general I do *not* consider our deprecation policy to apply to
*mandatory* build dependancies. Instead our platform support policy
applies.

The rationale is that mandatory build dependancies are not something
that can be considered on a case by case basis. To build QEMU on any
given platform, *all* the mandatory build deps must be satisfied by
that platform. Increasing min version of any single mandatory, build
dep will effectively exclude a host build target.

IOW, when we drop a build target we can consider updating min version
of *all* mandatory build deps at the same time.

Where the deprecation policy could come into play is if we want to drop
an *optional* build dependancy for certain platforms. eg librbd is an
optional build dep and we might have some reason we want to increase the
min version despite it not being present in all our supported platforms.
This could be a case to mark the "rbd" feature as deprecated on certain
build platforms.


Thus to answer your python 2 question, we should ask which of our build
targets cannot support python 3 ?

Obviously we know the answer to that is RHEL-7. Except there is some
fuzziness in there because it depends on what you define "RHEL-7" to
be. There are several possible answers

 a. RHEL-7 covers only the stuff in the basic yum repos
 b. RHEL-7 covers packages in any yum repos shipped by Red Hat
 c. RHEL-7 covers packages in any yum repos shipped by Red Hat or EPEL
 d. RHEL-7 covers packages in any yum repo available for use
    with RHEL-7,  provided by any vendor

The platform support policy has not documented which of these possiblities
we're targetting.

If we consider it to mean (a), then there's no way to use py3 with RHEL-7.

With (b), (c), or (d) it is possible to get py3 available on RHEL-7 by
enabling suitable repos.

Personally I think it would be fine for use to consider (b) or (c) to be
our intended interpretation for platform support policy.

In this interpretation it is possible for developers to get Python 3 on
RHEL-7 by enabling the Red Hat Software collection repos:

  https://developers.redhat.com/products/softwarecollections/hello-world/#fndtn-windows

This implies we *can* drop python2 from QEMU *and* keep RHEL-7 as a
supported target.

Also note that the platform support policy didn't say anything about
RHEL minor updates. ie it does not distinguish RHEL-7.0 from RHEL-7.6,
despite fact that some packages get major version rebases. I think we
should clarify that we mean "latest available updates" for our supported
platforms. ie 7.6 is supported, 7.0 is *not* supported.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2019-06-05 15:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31 19:24 [Qemu-devel] Deprecation policy and build dependencies Eduardo Habkost
2019-05-31 22:06 ` John Snow
2019-06-03 12:26   ` Markus Armbruster
2019-06-03 18:02     ` John Snow
2019-06-03 18:16       ` Cornelia Huck
2019-06-03 19:44         ` Eduardo Habkost
2019-06-04  7:14         ` Philippe Mathieu-Daudé
2019-06-03 18:17       ` Peter Maydell
2019-06-03 18:21         ` John Snow
2019-06-03 18:27           ` Peter Maydell
2019-06-03 18:38             ` John Snow
2019-06-04  5:31             ` Markus Armbruster
2019-06-04 15:51               ` John Snow
2019-06-04  5:26       ` Gerd Hoffmann
2019-06-05 15:50     ` Daniel P. Berrangé
2019-06-05 20:13       ` Eduardo Habkost
2019-06-05 20:42         ` Eric Blake
2019-06-05 20:49           ` Eduardo Habkost
2019-06-05 22:02             ` Eric Blake
2019-06-06  5:22           ` Markus Armbruster
2019-06-06  9:19           ` Daniel P. Berrangé
2019-06-05 15:44 ` Daniel P. Berrangé [this message]
2019-06-05 18:13   ` Eduardo Habkost
2019-06-06  9:23     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190605154403.GH8956@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).