[lfs-support] LFS-8.2: Chapter 6 Python3

[scrat]

FYI


Unpacked the python3 tar ball and it seems that the files: Lib/cgi.py T
and Tools/pybench/pybench.py contain a bang line of !/usr/local/bin/python


I don't know if it causes any errors, but the patched version I complied
is working so far as I use python3 with rpm package manager

I found the following tid bit in a rpm source file that i found looking
on the internet  and  used it to patch the files

    #removing reference to /usr/local/bin/python within
    #files to avoid a false dependencies
    sed -i                            \
        -e 's:^#!./usr/local/bin/python:#!/usr/bin/python:'    \
        -e 's:^#!/usr/local/bin/python:#!/usr/bin/python:'    \
        Lib/cgi.py                    \
        Tools/pybench/pybench.py

Here is what I did

    sed -i                            \
        -e 's:^#!./usr/local/bin/python:#!/usr/bin/python:'    \
        -e 's:^#!/usr/local/bin/python:#!/usr/bin/python:'    \
        Lib/cgi.py                    \
        Tools/pybench/pybench.py
    ./configure \
        --prefix=%{_prefix} \
        --enable-shared \
        --with-system-expat \
        --with-system-ffi \
        --with-ensurepip=yes
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Pos

[Bruce Dubbs]

Post by scrat
FYI
Unpacked the python3 tar ball and it seems that the files: Lib/cgi.py T
and Tools/pybench/pybench.py contain a bang line of !/usr/local/bin/python
I don't know if it causes any errors, but the patched version I complied
is working so far as I use python3 with rpm package manager
I found the following tid bit in a rpm source file that i found looking
on the internet  and  used it to patch the files
    #removing reference to /usr/local/bin/python within
    #files to avoid a false dependencies
    sed -i                            \
        -e 's:^#!./usr/local/bin/python:#!/usr/bin/python:'    \
        -e 's:^#!/usr/local/bin/python:#!/usr/bin/python:'    \
        Lib/cgi.py                    \
        Tools/pybench/pybench.py
Here is what I did
    sed -i                            \
        -e 's:^#!./usr/local/bin/python:#!/usr/bin/python:'    \
        -e 's:^#!/usr/local/bin/python:#!/usr/bin/python:'    \
        Lib/cgi.py                    \
        Tools/pybench/pybench.py
    ./configure \
        --prefix=%{_prefix} \
        --enable-shared \
        --with-system-expat \
        --with-system-ffi \
        --with-ensurepip=yes

First of all, you can make the sed a lot simplier:

sed -i '/^#!.*local\//s|local/||' Lib/cgi.py Tools/pybench/pybench.py

or even

sed -i '1 s|local/||' Lib/cgi.py Tools/pybench/pybench.py

Second, pybench.py is not installed by default.

Third, there is this:

# NOTE: the above "/usr/local/bin/python" is NOT a mistake. It is
# intentionally NOT "/usr/bin/env python". On many systems
# (e.g. Solaris), /usr/local/bin is not in $PATH as passed to CGI
# scripts, and /usr/local/bin is the default directory where Python is
# installed, so /usr/bin/env would be unable to find python. Granted,
# binary installations by Linux vendors often install Python in
# /usr/bin. So let those vendors patch cgi.py to match their choice
# of installation.

Finally, I'll note that this is the first come this has come up. cgi.py
is for using cgi type capabilities when creating scripts for a web
server. This has been deprecated for quite a few years now. The only
reason is is still in Python at all is for legacy web sites.

If users need this, they should be able to figure it out on their own.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wiki

[Jean-Marc Pigeon]

Hello Bruce,

Post by Bruce Dubbs

Post by scrat
FYI
Unpacked the python3 tar ball and it seems that the files: Lib/cgi.py
T and Tools/pybench/pybench.py contain a bang line of
!/usr/local/bin/python
I don't know if it causes any errors, but the patched version I
complied is working so far as I use python3 with rpm package manager
I found the following tid bit in a rpm source file that i found
looking on the internet and used it to patch the files
#removing reference to /usr/local/bin/python within
#files to avoid a false dependencies
sed -i \
-e 's:^#!./usr/local/bin/python:#!/usr/bin/python:' \
-e 's:^#!/usr/local/bin/python:#!/usr/bin/python:' \
Lib/cgi.py \
Tools/pybench/pybench.py
Here is what I did
sed -i \
-e 's:^#!./usr/local/bin/python:#!/usr/bin/python:' \
-e 's:^#!/usr/local/bin/python:#!/usr/bin/python:' \
Lib/cgi.py \
Tools/pybench/pybench.py
./configure \
--prefix=%{_prefix} \
--enable-shared \
--with-system-expat \
--with-system-ffi \
--with-ensurepip=yes

sed -i '/^#!.*local\//s|local/||' Lib/cgi.py Tools/pybench/pybench.py
or even
sed -i '1 s|local/||' Lib/cgi.py Tools/pybench/pybench.py
Second, pybench.py is not installed by default.
# NOTE: the above "/usr/local/bin/python" is NOT a mistake. It is
# intentionally NOT "/usr/bin/env python". On many systems
# (e.g. Solaris), /usr/local/bin is not in $PATH as passed to CGI
# scripts, and /usr/local/bin is the default directory where Python is
# installed, so /usr/bin/env would be unable to find python. Granted,
# binary installations by Linux vendors often install Python in
# /usr/bin. So let those vendors patch cgi.py to match their choice
# of installation.
Finally, I'll note that this is the first come this has come up. cgi.py
is for using cgi type capabilities when creating scripts for a web
server. This has been deprecated for quite a few years now. The only
reason is is still in Python at all is for legacy web sites.
If users need this, they should be able to figure it out on their own.
-- Bruce

As the original code writer (I do recognize my "style" :-}) let me give
my 2 cents
- My sed substitution is a very big overkill (trying to make 105% sure
not the change other code part). your proposal is better (thank Bruce)
- seems scrat went on OUSKISS repository and look for RPM solution
(no problem scrat, sharing and improving ideas and solutions is always
good).
The problem is RPM refusing to install python3 as there is
implied dependency with a none existing path.
- IMHO, this RPM problem/solution doesn't concern LFS, as
it is pure RPM problem and LFS do not address packaging issue.
Such adding this "twist" is not relevant to LFS book (my 2 Cents).

[scrat]

Post by Jean-Marc Pigeon
Hello Bruce,

Post by Bruce Dubbs

Post by scrat
FYI
Unpacked the python3 tar ball and it seems that the files: Lib/cgi.py
T and Tools/pybench/pybench.py contain a bang line of
!/usr/local/bin/python
I don't know if it causes any errors, but the patched version I
complied is working so far as I use python3 with rpm package manager
I found the following tid bit in a rpm source file that i found
looking on the internet  and  used it to patch the files
     #removing reference to /usr/local/bin/python within
     #files to avoid a false dependencies
     sed -i                            \
         -e 's:^#!./usr/local/bin/python:#!/usr/bin/python:'    \
         -e 's:^#!/usr/local/bin/python:#!/usr/bin/python:' \
         Lib/cgi.py                    \
         Tools/pybench/pybench.py
Here is what I did
     sed -i                            \
         -e 's:^#!./usr/local/bin/python:#!/usr/bin/python:'    \
         -e 's:^#!/usr/local/bin/python:#!/usr/bin/python:' \
         Lib/cgi.py                    \
         Tools/pybench/pybench.py
     ./configure \
         --prefix=%{_prefix} \
         --enable-shared \
         --with-system-expat \
         --with-system-ffi \
         --with-ensurepip=yes

sed -i '/^#!.*local\//s|local/||' Lib/cgi.py Tools/pybench/pybench.py
or even
sed -i '1 s|local/||' Lib/cgi.py Tools/pybench/pybench.py
Second, pybench.py is not installed by default.
# NOTE: the above "/usr/local/bin/python" is NOT a mistake.  It is
# intentionally NOT "/usr/bin/env python".  On many systems
# (e.g. Solaris), /usr/local/bin is not in $PATH as passed to CGI
# scripts, and /usr/local/bin is the default directory where Python is
# installed, so /usr/bin/env would be unable to find python. Granted,
# binary installations by Linux vendors often install Python in
# /usr/bin.  So let those vendors patch cgi.py to match their choice
# of installation.
Finally, I'll note that this is the first come this has come up.  cgi.py
is for using cgi type capabilities when creating scripts for a web
server.  This has been deprecated for quite a few years now. The only
reason is is still in Python at all is for legacy web sites.
If users need this, they should be able to figure it out on their own.
   -- Bruce

As the original code writer (I do recognize my "style" :-}) let me give
my 2 cents
- My sed substitution is a very big overkill (trying to make 105% sure
  not the change other code part). your proposal is better (thank Bruce)
- seems scrat went on OUSKISS repository and look for RPM solution
  (no problem scrat, sharing and improving ideas and solutions is always
   good).
  The problem is RPM refusing to install python3 as there is
  implied dependency with a none existing path.
- IMHO, this RPM problem/solution doesn't concern LFS, as
  it is pure RPM problem and LFS do not address packaging issue.
  Such adding this "twist" is not relevant to LFS book (my 2 Cents).

I never have had a problem with rpm installing python3 it has always
worked fro me and I have been building LFS with rpm since 2014.

Several others use my repo on github to build their systems

The only problem I have is rpm picking up dependecies when there isn't one.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in