CentOS 8 - no python

Tue Jan 9 16:38:04 UTC 2024

Chris.. an RSB feature submission question at the bottom.

Rest inlined.

On Tue, Jan 9, 2024 at 9:30 AM Michael G. South <msouth at msouth.org> wrote:

>
> > On Jan 8, 2024, at 10:53 , Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Mon, Jan 8, 2024 at 10:13 AM Frank Kühndel <
> frank.kuehndel at embedded-brains.de> wrote:
> > Hi Joel,
> >
> > have a great 2024!
> >
> > On 12/24/23 22:16, Joel Sherrill wrote:
> >  > Hi
> >  >
> >  > Trying to bring up Coverity builds on a Centos 8 machine, I ran into
> > this:
> >  >
> >  > + ../source-builder/sb-set-builder --log=l-sparc.txt
> >  > --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
> >  > build at rtems.org  --mail-from=joel at rtems.org 6/rtems-sparc
> >  >
> >  > /usr/bin/env: ‘python’: No such file or directory
> >  >
> >  > There is, in fact, no python executable -- there is python2 and
> python3.
> >  >
> >  > Suggestions other than adding a symlink?
> >
> > In RHEL 9.3 there exists the package python-unversioned-command which
> > creates a "python" command for "python3". I do not know whether it
> > exists in CentOS 8.
>

It appears to exist via Google but this was also suggested:

$ alternatives --set python /usr/bin/python3

Or select Python 2.

FWIW I think CentOS 8 is the last RHEL version to include Python 2.

> >
> > Thanks. It looks like CentOS 8 has that package but the computer is down
> right now.
> >
> > It is on a UPS that needs a new battery. So not much use. :(
> >
> > --joel
> >
> > Greetings,
> > Frank
> >
> > --
> > embedded brains GmbH & Co. KG
> > Herr Frank KÜHNDEL
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: frank.kuehndel at embedded-brains.de
> > phone:  +49-89-18 94 741 - 23
> > mobile: +49-176-15 22 06 - 11
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRA 117265
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> This might become an ongoing problem. As distros drop Python 2 support
> they have a tendency to also just drop “python” -> “pythonX” links. The
> Official Word ( https://peps.python.org/pep-0394/ ) is kind of weak-kneed
> about how “Python script publishers” should approach the issue, but
> basically says to either use a virtual environment, or figure out whether
> “python” or “python3” works and then use that.
>

Yep. I think the Python folks really made a mess with this transition. And
there are bumps in the 3.x series where things change. It is just messy.

In my standards work, I remind folks that if we need to fix/change
something that we should find a way to fix the issue so the fewest set of
users are impacted. The Python authors are a much smaller subset than
Python users. This is just whining I suppose.

>
> Does source builder still work with Python 2? I seem to recall the answer
> is “no,” that the gcc (or maybe lib?) build breaks with p2. If it does
> still work, is that an explicit goal for SB, and are there regression tests
> to avoid bit rot?
>

User facing tools like the RSBand waf  are supposed to work with Python 2
or 3. OAR actively tests on CentOS 7 which is Python 2.

But.. developer facing tools can require Python 3.  The documentation uses
Sphinx which requires Python 3. I had a virtual environment on CentOS 7 to
build this. CentOS/RHEL have a concept of software collections to let you
get newer tools like gcc or Python.

At some point, I assume Python 2 will become rare enough in the user
community that we won't care to support it any longer. Guessing, I would
suspect RTEMS 6 could be the last major release to worry about Python 2.

> As an aside, SB isn’t building on macOS Catalina for a similarish reason;
> there’s a path issue with the default Apple Python install, same issue with
> the official python.org  macOS bundles, and Homebrew patched it but no
> longer supports an old-enough python3 version that doesn’t break the GCC
> builds for other reasons.
>
> I think “the right way” would be to have sb/linux.py figure out the
> correct path for Python and pass that to the rest of the build. Though a
> lot more work in this particular case.
>
> Would you be interested in a patch to linux.py/rest of SB that
> implemented such a thing?
>

I cc'ed Chris about this. I expect it would be appreciated. If he doesn't
reply to this email thread,  please just email the patch to devel@ and
let's see the reaction.

--joel

>
> Mike
>
> --
>
> Michael South
> msouth at msouth.org
> LinkedIn:  www.linkedin.com/in/msouth
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240109/2fe34b52/attachment.htm>