Hey folks!
I'm working on a Python app that's structured in modules, but I haven't packaged it yet. I'm a bit puzzled about where to install these modules on different Linux distributions.
On Debian 12, I can install under "/usr/lib/python3/dist-packages/appname/". However, on AlmaLinux 10 (and other EL systems), I can choose between "/usr/lib/python3.12/site-packages/appname/" and "/usr/lib64/python3.12/site-packages/appname/".
So, I've got a couple of questions:
1. Why does Debian only have the /usr/lib directory without a /usr/lib64 for Python?
2. On EL systems, when should I choose /usr/lib/pythonx.x versus /usr/lib64/pythonx.x?
Thanks a lot for any insights!
3 Answers
The lack of /usr/lib64 is a legacy choice from when 32-bit and 64-bit libraries coexisted. Debian revamped its multi-arch system years ago. For AlmaLinux, I'd guess these directories are separate, but it’s possible /usr/lib64 could be symlinked to /usr/lib for compatibility.
It's better to avoid installing modules globally - consider using virtual environments (venvs). This way, you won't mess up your system's Python installation and keep everything organized!
Thanks for the advice! But why is global installation considered messy?
To answer your first question about Debian not having a /usr/lib64 directory: Debian handles multi-architecture in a unique way. Fedora-style systems like EL use distinct directories for 32-bit and 64-bit modules. Debian's method is a bit more complex, and you can check the rules files for specifics.
As for your second question, if you’re packaging with RPM, use the convenience macros to let the system dictate where to install. If not packaging, avoid installing in system directories - it's against best practices to prevent conflicts.
Appreciate the detailed response, Gordon!
So they're separate? That's interesting!