All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] python 3.5 compatibility
Date: Tue, 1 Dec 2020 16:39:24 +0000	[thread overview]
Message-ID: <20201201163924.GF2139284@redhat.com> (raw)
In-Reply-To: <20f78421-28b7-93d1-a691-05d6e98da5dc@metux.net>

On Tue, Dec 01, 2020 at 04:59:23PM +0100, Enrico Weigelt, metux IT consult wrote:
> On 01.12.20 07:33, Markus Armbruster wrote:
> 
> > Which has oldstable status.  Good for running the old and stable
> > software packaged by it (such as QEMU 2.8), and old (and hopefully
> > stable) software of similar vintage.
> 
> It's still heavily used out in the field, and officially supported.
> But that's just one example.
> 
> Perhaps I should add some more details on the situation: I'm using
> (specially built) qemu with ptxdist/dkit - not the distro package.
> The idea w/ ptxdist is that you just pull the trigger and it builds
> everything needed for some project. Qemu is built specifically for
> the configured target. Perhaps you've noticed I'm also doing development
> of new qemu features - something that one doesn't want to do on old
> versions.
> 
> > Have you considered upgrading to stable?
> 
> This would solve the problem just for me alone, not for others out
> there, who're working w/ the BSP. And asking everybody (especially in
> enterprise environments) to do a full release upgrade just for one
> single tool (qemu) isn't someting that works easily.
> 
> If you insist in having python3.6 a hard requirement for qemu, you're
> putting me into the situation of having to do lots of backport work
> for quite long time (until everybody really did the upgrade). :(

python3.6 is just the one problem you've currently hit. In order to keep
the burden of maintaining support for old software under control we have
a well defined set of platforms that we target. When a particular version
of a distro drops off our list, we will bump the minimum versions of any
software we depend on. In this case you've hit python3.6 so far, but we
are liable to bump other minimum versions too which will also impact
this old distro. So I'm afraid it will be a loosing battle to stay on
this old distro, while building cutting edge QEMU.

I appreciate this isn't the answer you want to hear, but we've defined
our support platform matrix to try to balance multiple competing factors
and unfortunately this means distros are going to periodically get dropped
by new QEMU as they get older.

One possible way you can mitigate this is to make use of containers for
your development and deployment. eg even tough you're using an old
Devuan, you can use docker/podman to build and deploy QEMU inside a
stable Devuan container.

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 :|



  reply	other threads:[~2020-12-01 16:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27 18:36 [PATCH] python 3.5 compatibility Enrico Weigelt, metux IT consult
2020-11-27 19:15 ` Peter Maydell
2020-11-30 18:27   ` Enrico Weigelt, metux IT consult
2020-12-01  6:33     ` Markus Armbruster
2020-12-01 15:59       ` Enrico Weigelt, metux IT consult
2020-12-01 16:39         ` Daniel P. Berrangé [this message]
2020-12-01  7:32     ` Marc-André Lureau
2020-11-30  9:44 ` Kevin Wolf
2020-11-30 18:30   ` Enrico Weigelt, metux IT consult

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=20201201163924.GF2139284@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=lkml@metux.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.