roles/python-venv: Folder is handled the wrong way

[markuslf]

The filesystem hierarchy standard says that each add-on package under /opt should live in its own top-level subdirectory (e.g. /opt/<vendor-or-pkg-name>). By creating a shared /opt/python-venv namespace for many venvs, we're effectively putting multiple products under one tree.

There are also differences between RHEL and Debian (especially Debian 12) on where to put Python venvs the right way.

[markuslf]

We looked into what the Python project itself recommends for the location of system-wide virtual environments on servers. The short answer: there is no official recommendation.

• PEP 405 defines the technical mechanics of venvs but does not prescribe a filesystem location.
• The discussions on discuss.python.org focus on whether to use venvs (yes), but not where to place them on servers. /opt is not mentioned in any of these discussions.

The Filesystem Hierarchy Standard (FHS 3.0) is more opinionated: /opt is for add-on application software packages, and each package must have its own top-level directory (/opt/<package>). A shared /opt/python-venv namespace for multiple products violates this. Other common locations like /usr/local (designed for software that splits across its bin/, lib/, share/ subdirectories) or /var/lib (intended for application state data, not installed software) are a worse fit for self-contained venv directories. Since our venvs provide standalone tools like duplicity or fangfrisch, /opt/<name> is the most appropriate location according to the FHS.

RFC: Change from /opt/python-venv/<name> to /opt/<name> in LFOps. This removes the artificial grouping directory and aligns with the FHS. The python-venv role will no longer create or manage /opt/python-venv. The updated role would automatically move existing venvs from /opt/python-venv/<name> to /opt/<name> and clean up the old directory once empty.