linda ... Re: Correct location of .py and .pyc files
-----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 <paganini-debian-lists@paganini.net> 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-----
Reply to: