Florent Rougon writes:
> 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.
Joss proposal is already incorporated into the proposed policy found
in the python package.
There is no reason why /usr/share/<module> should be disallowed. I
changed the proposed policy to:
--- debian/python-policy.sgml~ 2003-10-05 20:46:30.000000000 +0200
+++ debian/python-policy.sgml 2003-11-16 11:50:47.000000000 +0100
@@ -553,13 +553,15 @@
<tt>/usr/lib/site-python/<var>module</var></tt>,
<tt>/usr/lib/python<var>X</var>.<var>Y</var>/site-packages/<var>module</var></tt>
(where python<var>X</var>.<var>Y</var> is the current
- python version) or
- <tt>/usr/lib/<var>package</var></tt>. In the latter case,
- this directory should be added to <tt>sys.path</tt> at the
- program startup. The latter case is recommended, if the
- private modules would pollute the name space in
- <tt>sys.path</tt>.
-
+ python version).
+ </p>
+ <p>
+ If the private modules would pollute the name space in
+ <tt>sys.path</tt>, the modules should be installed in
+ <tt>/usr/lib/<var>package</var></tt> (for architecture
+ any) or <tt>/usr/share/<var>package</var></tt> (for
+ architecture all). In this case, the directory should be
+ added to <tt>sys.path</tt> at the program startup.
</p>
<p>
Such a package must depend on
