[SOLVED] current: python-3.11 x86-64 site-packages under /usr/lib

marrowsuck · 03-31-2024, 01:45 PM

Several x86_64 python libs are now under '/usr/lib/python3.11/site-packages' instead of '/usr/lib64/python3.11/site-packages/'

python3 -m sites now also lists '/usr/lib/python3.11/site-packages'.

fourtysixandtwo · 03-31-2024, 01:53 PM

Quote:

Originally Posted by marrowsuck

Several x86_64 python libs are now under '/usr/lib/python3.11/site-packages' instead of '/usr/lib64/python3.11/site-packages/'

python3 -m sites now also lists '/usr/lib/python3.11/site-packages'.

Just had this conversation in another thread, there's a note in the setuptools slackbuild about it.
https://www.linuxquestions.org/quest...ml#post6493214

volkerdi · 03-31-2024, 01:54 PM

Quote:

Originally Posted by marrowsuck

Several x86_64 python libs are now under '/usr/lib/python3.11/site-packages' instead of '/usr/lib64/python3.11/site-packages/'

python3 -m sites now also lists '/usr/lib/python3.11/site-packages'.

Here's a couple of commands that you should test:

Code:

find /usr/lib/python3.11 -type f | xargs file | grep x86-64
find /usr/lib64/python3.11 -type f | xargs file | grep x86-64

You'll notice that only under /usr/lib64 are there any Linux ELF x86-64 objects.

There do however, seem to be some x86-64 Windows turds under /usr/lib, and maybe something should be done about that.

It's still up in the air how multilib will react to this, but I suspect that python knows to look for binary objects in the platform library directory, and for any architecture independent files in the "purelib" (i.e. under /lib).

Another reference:

https://stackoverflow.com/questions/...latlib-purelib

As you can see, we were doing things differently from upstream (and pretty much everyone else) since the time of Slackware 13.0.

Daedra · 03-31-2024, 01:54 PM

Quote:

Originally Posted by marrowsuck

Several x86_64 python libs are now under '/usr/lib/python3.11/site-packages' instead of '/usr/lib64/python3.11/site-packages/'

python3 -m sites now also lists '/usr/lib/python3.11/site-packages'.

From Pat's Python-setuptools SlackBuild

Code:

# After Python 3.9, we will not mess with the upstream module layout again.
if python3 --version | grep -q "Python 3.9." ; then
  # Recent Python versions support both a libdir (for pure Python modules) and a
  # platlib (for $ARCH specific modules). We've always patched Python to use
  # the platform directory (such as /usr/lib64/python3.9/site-packages on x86_64)
  # for all modules. Perhaps we will rethink this, but since an installed
  # setuptools now takes priority for reporting the libdir (and this no longer
  # matches the platlib on architectures such as x86_64), let's patch setuptools
  # to agree with Python:
  if [ "$LIBDIRSUFFIX" = "64" ]; then
    zcat $CWD/setuptools.x86_64.diff.gz | patch -p1 --verbose || exit 1
  fi
fi

Thanks to fourtysixandtwo for pointing this out to me

marrowsuck · 03-31-2024, 02:11 PM

Alright! I'm reliefed. No more packaging today.
Thanks a lot for the clarification.

fourtysixandtwo · 03-31-2024, 02:12 PM

Quote:

Originally Posted by volkerdi

Here's a couple of commands that you should test:

Code:

find /usr/lib/python3.11 -type f | xargs file | grep x86-64
find /usr/lib64/python3.11 -type f | xargs file | grep x86-64

You'll notice that only under /usr/lib64 are there any Linux ELF x86-64 objects.

There do however, seem to be some x86-64 Windows turds under /usr/lib, and maybe something should be done about that.

It's still up in the air how multilib will react to this, but I suspect that python knows to look for binary objects in the platform library directory, and for any architecture independent files in the "purelib" (i.e. under /lib).

Another reference:

https://stackoverflow.com/questions/...latlib-purelib

As you can see, we were doing things differently from upstream (and pretty much everyone else) since the time of Slackware 13.0.

I can see that separation being useful. Any thought to setting noarch for the python packages that qualify?

volkerdi · 03-31-2024, 02:24 PM

Quote:

Originally Posted by fourtysixandtwo

I can see that separation being useful. Any thought to setting noarch for the python packages that qualify?

Since there's no guarantee that a package like that would remain noarch, probably it's safer to not do that.

chrisretusn · 04-02-2024, 08:39 AM

Quote:

Originally Posted by volkerdi

Here's a couple of commands that you should test:

Code:

find /usr/lib/python3.11 -type f | xargs file | grep x86-64
find /usr/lib64/python3.11 -type f | xargs file | grep x86-64

You'll notice that only under /usr/lib64 are there any Linux ELF x86-64 objects.

I checked with all of my third party packages. I've noticed that only the packages that do not have Linux ELF x86-64 objects are going in to /usr/lib. Packages with Linux ELF x86-64 objects are going to /usr/lib64.

I do have one exception. A third party program, flann. It places in python binding in /usr/lib.

Code:

find /usr/lib/python3.11 -type f | xargs file | grep x86-64
/usr/lib/python3.11/site-packages/pyflann/lib/libflann.so:                                                            ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, stripped

I'm absolutely okay with python doing what it doing.