On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote:
> This would mean we'd need to split e.g. python-gtk2 into five. Do we really
> want
> that? The "should" wording allowed one to not do it in special cases. I'm not
> saying we shouldn't change it, but we should make sure we're aware of all the
> consequences of the change...
How about the new attached patch, "Require the python- prefix for
public modules"?
--
Loïc Minier
>From 95d0258fb8513078ccb3eb496a7867c16de4f747 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= <l...@dooz.org>
Date: Fri, 11 Dec 2009 11:00:24 +0100
Subject: [PATCH 28/30] Require the python- prefix for public modules
Require the python- prefix for packages shipping public modules used by
other packages, and recommend using python-foo for public modules in
general but allow for package shipping multiple modules; thanks Luca
Falavigna and Emilio Pozuelo Monfort.
---
debian/python-policy.sgml | 23 +++++++++++++++--------
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index e8d7e3a..bdbc541 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -387,14 +387,21 @@
<sect id="package_names">
<heading>Module Package Names</heading>
<p>
- Public modules should have a binary package named
- <package>python-<var>foo</var></package>,
- where <var>foo</var> is the name of the module. Such a
- package should support the current Debian Python version,
- and more if possible (there are several tools to help
- implement this, see <ref id="packaging_tools">). For
- example, if Python 2.3, 2.4, and 2.5 are supported, the
- Python command
+ Public modules used by other packages must have their binary
+ package name prefixed with <var>python-</var>. It is recommended
+ to use this prefix for all packages with public modules as they be
+ used by other packages in the future.
+
+ The binary package for module foo should preferably be named
+ <package>python-<var>foo</var></package>, if the module name
+ allows, but this is not required if the binary package ships
+ multiple modules. In the latter case the maintainer choses the
+ name of the module which represents the package the most.
+
+ Such a package should support the current Debian Python version,
+ and more if possible (there are several tools to help implement
+ this, see <ref id="packaging_tools">). For example, if Python 2.3,
+ 2.4, and 2.5 are supported, the Python command
<example>
import foo
</example>
--
1.6.5
