From: Adrian Bunk <bunk@stusta.de>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 01/13] python: update to 2.7.17
Date: Sat, 30 Nov 2019 11:49:48 +0200 [thread overview]
Message-ID: <20191130094948.GA4526@localhost> (raw)
In-Reply-To: <CANNYZj_2+0+6Suq0Gu74t+QDhx3mdb6FZsr2mwy8WhtNk493ug@mail.gmail.com>
On Tue, Nov 19, 2019 at 12:30:41PM +0100, Alexander Kanavin wrote:
> On Tue, 19 Nov 2019 at 08:58, Tim Orling <ticotimo@gmail.com> wrote:
>
> > I have the beginnings of scripts to generate a meta-python2 layer. Someone
> > with a vested interest in keeping python2 supported will need to step up to
> > maintain it. After bitbake and Oe-core moved to python3, my use of python2
> > has gone to near zero.
> >
> > I intend to move all python2 recipes from meta-python to the new layer.
> > meta-python will become python3 only in 3.1 release timeframe. The bb files
> > and inc files will also be merged, simplifying AUH and devtool usage.
> >
> > Attempts to send python2 patches to meta-python after that shift will be
> > nacked.
>
> Thanks! There is however a missing part: how close is meta-oe to being
> py2-free? Oe-core is very close (u-boot is the last holdout as noted), but
> I am not sure that we can simply take out py2, and not have half of meta-oe
> fail. For instance (random example) mozjs, a fairly important component,
> still pulls it in, together with a few 3rd party libraries:
> https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/mozjs/mozjs_60.5.2.bb
>
> It's tempting to force the transition by breaking things, but it also
> antagonizes users.
The problem is not that half of meta-oe would fail, but the few hard cases.
There might be 1 or 2 recipes where the rational solution would be to
keep Python 2 in meta-oe for one release until a new upstream of these
recipes solves the problem.
AFAIK for nodejs the choice for Yocto 3.1 will be between a short-term
stable that can be built with Python 3 but will become EOL shortly after
Yocto 3.1 releases, and an LTS release with upstream support for 2 more
years that needs Python 2.
Python 2 is security supportable without upstream support since many
other distributions have committed to do the same, security supporting
Node.js without upstream support might be impossible.
> Alex
cu
Adrian
next prev parent reply other threads:[~2019-11-30 9:49 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 13:07 [PATCH 01/13] python: update to 2.7.17 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 02/13] runqemu: add options that enable virgl with the SDL frontend Alexander Kanavin
2019-11-18 13:07 ` [PATCH 03/13] oe-selftest: extend virgl gtk test to also check the SDL option Alexander Kanavin
2019-11-18 13:07 ` [PATCH 04/13] tiff: update to 4.1.0 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 05/13] librepo: upgrade 1.10.6 -> 1.11.0 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 06/13] btrfs-tools: upgrade 5.3 -> 5.3.1 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 07/13] psmisc: update to 23.3 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 08/13] libxslt: update to 1.1.34 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 09/13] Revert "devtool/standard.py: Not filtering devtool workspace for devtool finish" Alexander Kanavin
2019-11-18 13:07 ` [PATCH 10/13] mpg123: upgrade 1.25.12 -> 1.25.13 Alexander Kanavin
2019-11-18 13:07 ` [PATCH 11/13] vala: upgrade 0.46.3 -> 0.46.4 Alexander Kanavin
2019-11-18 13:08 ` [PATCH 12/13] systat: upstream version check is working again Alexander Kanavin
2019-11-18 13:47 ` Peter Kjellerstedt
2019-11-18 13:08 ` [PATCH 13/13] man-pages: correct the SRC_URI Alexander Kanavin
2019-11-18 13:31 ` ✗ patchtest: failure for "python: update to 2.7.17..." and 12 more Patchwork
2019-11-18 18:13 ` [PATCH 01/13] python: update to 2.7.17 Khem Raj
2019-11-18 21:05 ` Adrian Bunk
2019-11-18 21:39 ` Khem Raj
2019-11-18 22:06 ` Adrian Bunk
2019-11-18 22:16 ` Khem Raj
2019-11-18 22:34 ` Ross Burton
2019-11-18 22:55 ` Adrian Bunk
2019-11-18 23:26 ` Khem Raj
2019-11-19 7:57 ` Tim Orling
2019-11-19 11:30 ` Alexander Kanavin
2019-11-19 15:49 ` Khem Raj
2019-11-19 16:30 ` Adrian Bunk
2019-11-19 16:47 ` Khem Raj
2019-11-20 11:57 ` Ross Burton
2019-11-25 3:36 ` Adrian Bunk
2019-11-19 22:44 ` Andreas Müller
2019-11-30 9:49 ` Adrian Bunk [this message]
2019-11-19 11:24 ` Alexander Kanavin
2019-11-20 12:56 ` Tom Rini
2019-11-20 13:47 ` Alexander Kanavin
2019-11-20 13:50 ` Tom Rini
2019-11-20 15:06 ` Alexander Kanavin
2019-11-20 15:08 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2019-11-18 14:28 Alexander Kanavin
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=20191130094948.GA4526@localhost \
--to=bunk@stusta.de \
--cc=alex.kanavin@gmail.com \
--cc=openembedded-core@lists.openembedded.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.