On 25.02.22 14:16, Richard Purdie wrote:
On Thu, 2022-02-24 at 16:52 +0100, Konrad Weihmann wrote:
I got a kind of general question about this patch series and all the
followups: is this still considered to go into the next release?
It is still being considered, yes.
I'm a bit worried about the fallout of this pretty invasive change -
even though I see that at some point it needs to be done.
My understanding is that the "classic" way will stop with Python 3.12,
which doesn't apply to next LTS release - as this will likely remain on
3.10.
Only downside will be that manual helper files for updates of packages
that are lacking a setup.py needs to be provided (there are already a
few examples how to do it) - not a big deal if you'd ask me.
So what's the stand of the project regarding this issue - also keeping
in mind that I think it's already past feature freeze?
This is a tough one to make a decision on and I am conflicted. The change was
flagged up a while ago and has been regularly talked about. It is also something
we all agree will have to happen at some point.
The change is late and has issues but there was a base patchset sent before the
freeze deadline.
This isn't the final release point, it is the point where we stop taking new
invasive changes and stabilise and I think it important to keep that in mind.
Stepping back and thinking about the big picture (and e.g. the ability to take
security fixes into the LTS), I'm leaning towards trying to get it in. One other
consideration is having large delta between the LTS and onging development and
I'd prefer to minimise this particular difference if it is practical to do so.
Your argumentation does make sense, but I have to disagree on this
particular point.
The using pip as the default installer and therefore wheels is something
that will never (hopefully) get backported, so bringing this change in
automatically builds up a huge delta to any other branch - thus here you
would create a situation that (I agree) should be avoided.
Also moving around a few classes and recipe between core and
meta-python, will either bind users to including meta-python in every
setup or will create situation were people will try to work around these
changes.
I see that this feature has been promised - and it might be bad for the
project's reputation to drop it - still if one would ask me, I would
prefer to delay it to the next release.
One potential option would be to offer that one (once mature and tested
will a broad set of layers) as a mixin-layer, which then could be used
with kirkstone LTS
I believe we have identified and fixed the majority of the issues that have
shown up in automated testing.
I haven't made a final decision but I am keeping an open mind on it and would
really prefer to get it merged. There are other issues being worked in parallel
which also would block the M3 build which does give time to resolve this one.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162345):
https://lists.openembedded.org/g/openembedded-core/message/162345
Mute This Topic: https://lists.openembedded.org/mt/89324642/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
