But why a separate package? I don't understand why people keep insisting on it. There's no problem and no need to give it visibility, there's just historical baggage that we can now fix. We can just add the symlink from core package, drop all the sed hacks and rejected upstream patches (instead of tweaking RDEPENDS), and the only people affected would be those mysterious python 2.x users who would have to patch *their* scripts instead, as they should be in 2024, so that *they* know it's way past time to get rid of 2.x.
Master can and does break builds deliberately. There's not ever a promise to not do that. Alex On Tue, 23 Jul 2024 at 20:19, Konrad Weihmann <[email protected]> wrote: > > How about just moving it to an additional package out of the python recipe. > It's almost zero effort to implement and zero effort to maintain, while > not deliberately breaking builds (it's not that the users I know are > keen on keeping python2). > > basically a PACKAGE_BEFORE_PN = "python3-python-symlink" + > FILES:python3-python-symlink += "${bindir}/python" will do it. > > And those lines will most likely never ever change again. > > Like this it at least allows a RCONFLICTS to be properly propagated. > > Followups could then replace the unanswered/rejects patches by > RDEPENDing on that new package. > This will also help to maintain visibility on the problem. > > > On 23.07.24 19:56, Alexander Kanavin wrote: > > I guess the recommendation to remove the symlink if needed was a bit > > poorly thought out. > > > > On the other hand, I fail to see any benefit whatsoever in a separate > > python-is-python3. If you do not have python 2.x installed on target, > > there is no difference in whether there is a python symlink on the > > target or not. And if you do, you still have the same clash between > > 2.x scripts that refer to python, and 3.x scripts that refer to > > python, and no easy way to resolve that clash. > > > > What I am proposing instead is this: > > > > - python to python3 symlink is still provided by the base package. > > It's not accurate to say that 'patching' things from recipes to use > > python3 is what people 'prefer', it's that up until now they were > > forced to do it, Randy. > > > > - if anyone is still using python 2.x in target images in 2024 with > > yocto master (nevermind that the public python2 layer is dead and > > unmaintained), and is relying on python 2.x being symlinked to python, > > they should be adjusting their scripts to point to python2 instead. > > They no longer own the unversioned python symlink and we should not be > > catering to them. > > > > Please reframe your arguments. > > > > Alex > > > > On Tue, 23 Jul 2024 at 18:44, Randy MacLeod via lists.openembedded.org > > <[email protected]> wrote: > >> > >> On 2024-07-23 9:38 a.m., Konrad Weihmann via lists.openembedded.org wrote: > >> > >> I also vote against it. > >> > >> I'm on the fence but I'll be swayed by the "against" voters. > >> > >> There are pros and cons to a system-wide solution but it seems that > >> people prefer to have these problems fixed in each affected recipe. > >> Best solution is to update the script to call and work with python3. > >> If the upstream refuses to do that, the layer would have to carry a patch. > >> > >> This is how most such '/usr/bin/python' problems have been solved. > >> It's a shame that upstream python didn't mandate a specific solution. > >> > >> Btw, some people could use: > >> > >> https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb > >> https://github.com/Igalia/meta-webkit/commit/b2156c282a6e727100dee25155fbc38d1532b573 > >> https://github.com/Igalia/meta-webkit/commit/46fbfbc58f82abc3dc8794c630172d4554be0830 > >> > >> ❯ git log --stat 46fbfbc5 > >> commit 46fbfbc58f82abc3dc8794c630172d4554be0830 > >> Author: Carlos Alberto Lopez Perez <[email protected]> > >> Date: Mon Dec 19 20:29:05 2022 > >> > >> Add a new image and distro definition for using on the WebKit CI for > >> WPE perf bots > >> > >> ... > >> > >> * It adds also a 'python-is-python3' recipe that creates a symlink > >> to provide the unversioned python interpreter as python3. > >> > >> > >> but both oe-core and meta-oe maintainers said on today's YP tech call that > >> they would *not* carry that recipe. > >> > >> ../Randy > >> > >> > >> > >> > >> While I see the convenience in dropping a lot of patches the better > >> approach would be to add something like python-is-python3, for the ones > >> that require it. > >> (meta-webkit does provide it already > >> https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb). > >> > >> Adding a link by the base package and recommending to the user to remove > >> it again, would create two very unwelcome situations. > >> > >> a) it will clash at image assembly with an error message that will no > >> easily point to the python base package > >> b) create a need to run with a permanent remove operation on top of poky > >> (creating the need for new sstate cache artifacts) > >> > >> What I could see is to move the symlink into an optional package, which > >> could be used by the few recipes that still use the "wrong" interpreter > >> line via RDEPENDS, that would be the much cleaner solution here > >> > >> > >> > >> > >> -- > >> # Randy MacLeod > >> # Wind River Linux > >> > >> > >> > >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202417): https://lists.openembedded.org/g/openembedded-core/message/202417 Mute This Topic: https://lists.openembedded.org/mt/107264938/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
