-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I note that applications written in python, such as my aap package, go into /usr/lib/<package> per the policy (section 3.1.1), but linda does not support this. _all packages (most things written in Python) belong in /usr/share according to linda, but /usr/lib according to Python policy.
Of course I obey the policy and not linda, but this is annoying. (Particularly so when linda itself is written in Python -- and doesn't obey the Python policy! :-)
As long as I'm on my rant chair, is there any reason why packages with private modules need to be in /usr/lib? Python upstream doesn't care about private modules one way or the other.
C
Florent Rougon wrote: | [Ugh, sorry for the double message, Marco] | | Marco Paganini <[EMAIL PROTECTED]> wrote: | | |>Hi All, | | | Hi, | | |>I need to package a Python application that depends on multiple modules. |>I've been wondering about the correct location for the modules (both .py and |>.pyc files) in Debian. FHS states that architecture independent files should |>go under /usr/share/packagename, which was my first guess at where to put |>them. However, I checked some packages in the repository and they put those |>files in /usr/lib/packagename (!?). What is, after all, the blessed location |>for these files? | | | I think the status quo is: /usr/share would be better, but is not | supported upstream, and no one yet has been willing to put the energy | needed to solve this problem. OTOH, there could be some weird cases | where a Python script would be intended for specific architectures | (hence would have to live in /usr/lib), but I think most of them would | be fairly pathological and could be changed to work in /usr/share. | | As for now, the best location for these modules is | /usr/lib/pythonX.Y/site-packages. If the modules are | Python-version-independent, /usr/lib/python/site-packages (looks | deprecated; I have /usr/lib/site-python on my sid chroot instead) with | some mecanism like python-central would be better, but it seems to me it | isn't officially supported (there is no python-central package in | unstable and no register-python-package command in the | python(x.y)?(-dev)? packages), even though I used it on a package of | mine in my private apt repository, and found it to work well. | | |>Another point is what should be done with the "compiled" versions? Should the |>package installation scripts pre-compile the modules for faster execution? | | | Yes, but obviously you haven't read the Python policy draft | (/usr/share/doc/python/python-policy.txt.gz) nor Josselin's proposal at | http://people.debian.org/~joss/python/python-policy-draft.html/index.html. | They are must reads for anyone packaging something that is | python-related. |
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows 2000) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE/slv23A5SrXAiHQcRAmtNAKCh/CmJbW+duxksbQ82NJjzCZSThgCghLy6 LgoZjo75JoL1/HXzdXFfNZw= =9PMQ -----END PGP SIGNATURE-----
