Fyi, Chromium browser depends on lang/python27

Alain De Vos

Alain De Vos

I've blacklisted python27.
Skipping www/chromium | chromium-91.0.4472.114: Dependent port lang/python27 | python27-2.7.18_1 ignored
It seems Chromium browser still depends on it.
 
Yep, latest portsnap shows an explicit dependency for building Chromium. Quick glance at the Makefile I think it's a build dependency, not a runtime dependency, which means it probably flows down and around and through and over everything.
Without actually trying to build with python3 and looking at the logs, I can't say how trivial it would be to fix.
Oh, portsnap is not the same as git clone the ports. It's handy for just quickly looking at Makefiles and dependencies, but if I were building from ports I would git clone and then git checkout the branch I wanted.

Edit:
If you go look at your thread about "How do I know new quarterly packages arrived?" the linked email indicates that 2021-Q3 ports will be python3.8 based, with Chromium fixed for that. To me that indicates the port maintainer is actively working on it, but in a branch not on ports "main". I'm guessing that once it's committed to the branch, it will get merged up to main. But that is speculation on my part.
 
Alain De Vos said:
It seems Chromium browser still depends on it.
Click to expand...
It's a build dependency, not a run dependency. In other words, only required to build the port.

Code: 
root@molly:/usr/ports/www/chromium # make build-depends-list | grep python
/usr/ports/lang/python27
 
No, for a lot of ports Python 2.7 was actually a run dependency.
 
Alain De Vos said:
The only building dependencies have already been shown as showstoppers for some ports.
Click to expand...
And that is the correct/desired behavior.

Port A requires port X to build, say because of scripts used to configure the build. port X goes end of life, everyone should be using port Z instead of port X. Port X is removed from the tree. Port A now won't build until it is updated to use port Z, because port X has gone EOL and is no longer in the tree

That is entirely different from run dependencies as pointed out. You may be able to build something, but it won't install if a runtime dependency is not met. It's easier to check build and run dependencies before even building because, "it builds but won't install" is more frustrating than "oh it needs B as a run dependency" and install that upfront.
 
Python works as a filter for poorly maintened or maintanable ports.
Python38 is different from python27. I think the build proces of Chromium is also not the most simple.
But there where messages the maintainer of Chromium is working towards python38.
 
Chromium, like any other Google product is not a simple build process. I think it is on purpose (my opinion).
That is why being a port maintainer is a thankless job: users all want the latest version, but it takes time and effort to get there and when you do, you may already be behind again :)

Your first sentence, that is a reasonable idea, but I think the complete thought should be along the lines of:

"Python27 has gone end of life, Python38 replaces it. If I set DONT_USE_PYTHON27, what can't build? Out of the ports that can't build, which ones do I have installed? Out of the ones I have installed, which ones do I use, which ones can I get rid of?"

Any system gets cruft, garbage on it when used for a while. You try an application, it's dependencies get installed, you don't like it, but then you never remove it. You wind up with extra stuff on your system that you forget about until you do a complete upgrade/reinstall and you install fewer applications.

Kind of like moving your house every 5 years, you clean the attic, garage, basement and throw stuff away. If you wait 10 years, you have more to throw away.
 
From <https://bugs.chromium.org/p/chromium/issues/detail?id=942720#c83>:

… it should be possible to check out, build, and upload CLs using just py3 for chromium/src stuff (there are a couple of presubmit hooks that still need to be converted, but the vast majority is complete), although I think there are a couple things in depot_tools that might still require py2 (we're still working on upgrading gsutil to a py3-compatible version).

There has been progress on the testing front, but the tests as a whole did not complete in Q2. We're hoping for Q3, though. We're mostly blocked on Telemetry (which should be ready soon) and users of the Devil library needing to update stuff.

Recipe migration still will happen in Q3 and Q4.
Click to expand...
 
You must log in or register to reply here.
Back
Top