Re: RFC: Proposed updates to the Python Policy to reflect current practices
Hi Loïc! Loïc Minier wrote: Require the python- prefix for public modules 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... Regards, Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Require the python- prefix for public modules 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... Good point; I guess we want to require the python- prefix (at least when a dependency is involved), and a recommendation to use python-foo when shipping module foo (unless shipping multiple modules, or when the module name doens't allow so (underscores for instance). -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Tue, Dec 08, 2009, Jakub Wilk wrote:
+ versions explicitely.
You could fix that typo if you are at it.
Thanks; I've spell checked the whole document and came up with the
attached patch, Spell check fixes.
--
Loïc Minier
From ee2c89e0b24b2deff74ad35d59a8ca4a9f936ecf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org
Date: Fri, 11 Dec 2009 12:00:18 +0100
Subject: [PATCH 29/29] Spell check fixes
---
debian/python-policy.sgml | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 67e3d76..513200e 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -62,7 +62,7 @@
tt/usr/share/common-licences/GPL/tt in the Debian GNU/Linux
distribution or on the World Wide Web at
url id=http://www.gnu.org/copyleft/gpl.html;
- name=The GNU Public Licence.
+ name=The GNU Public License.
/p
p
You can also obtain it by writing to the
@@ -96,7 +96,7 @@
are needed by other packages, or as long as it seems
reasonable to provide them. (Note: For the scope of this
document, Python versions are synonymous to feature
- releases, i.e. Python 2.5 and 2.5.1 are subminor versions of
+ releases, i.e. Python 2.5 and 2.5.1 are sub-minor versions of
the same Python version 2.5, but Python 2.4 and 2.5 are
indeed different versions.)
/p
@@ -115,7 +115,7 @@
byte-compiled, old-versions which is the list of runtimes which
might still be on the system but for which should not be built
anymore, and unsupported-versions which is the list of runtimes
- which should not be supported at all, that is modules shouldn't be
+ which should not be supported at all, that is modules should not be
built or byte-compiled for these.
/p
p
@@ -186,11 +186,11 @@
p
Python scripts depending on the default Python version (see ref
id=base) or not depending on a specific Python version should
- use filepython/file (unversioned) as the interpreter name.
+ use filepython/file (without a version) as the interpreter name.
/p
p
Python scripts that only work with a specific Python version must
- explicitly use the versioned interpreter name
+ explicitly use the version-ed interpreter name
(filepythonvarX/var.varY/var/file).
/p
/sect1
@@ -285,7 +285,7 @@
There are three supported hook types which come in the form of
scripts which are invoked from the maintainer scripts of the
Python runtime packages when specific installations,
- uninstallations, or upgrades occur.
+ removals, or upgrades occur.
/p
penumlist
item
@@ -345,7 +345,7 @@
Python transitions. Python modules are internally very
dependent on a specific Python version. However, we want to
automate recompiling modules when possible, either during the
- upgrade itself (re-bytecompiling pyc and pyo files) or shortly
+ upgrade itself (re-byte-compiling pyc and pyo files) or shortly
thereafter with automated rebuilds (to handle C
extensions). These policies encourage automated dependency
generation and loose version bounds whenever possible.
@@ -378,8 +378,8 @@
modules are installed in a public directory as listed
in ref id=paths. They are accessible to any
program. Private modules are installed in a private directory such
- as file/usr/share/varpackagename/var/file
- or file/usr/lib/varpackagename/var/file. They are
+ as file/usr/share/varpackage-name/var/file
+ or file/usr/lib/varpackage-name/var/file. They are
generally only accessible to a specific program or suite of
programs included in the same package.
/p
@@ -446,7 +446,7 @@ XB-Python-Version: ${python:Versions}
yourself.) The format of the field ttXB-Python-Version/tt is
the same as the ttXS-Python-Version/tt field for packages not
containing extensions. Packages with extensions must list the
- versions explicitely.
+ versions explicitly.
/p
p
If your package is used by another module or application
@@ -489,11 +489,11 @@ XB-Python-Version: ${python:Versions}
/p
/sect
- sect id=bytecompilation
-headingModules Bytecompilation/heading
+ sect id=byte_compilation
+headingModules Byte-Compilation/heading
p
If a binary package provides any binary-independent modules
- (filefoo.py/file files), the corresponding bytecompiled
+ (filefoo.py/file files), the corresponding byte-compiled
modules (filefoo.pyc/file files) and optimized modules
(filefoo.pyo/file files) must not ship in the
package. Instead, they should be generated in the package's
@@ -534,7 +534,7 @@ XB-Python-Version: ${python:Versions}
begin with tt#!/usr/bin/python/tt or tt#!/usr/bin/env
python/tt (the former is preferred). They must also
specify a dependency on packagepython/package, with a
- versioned dependency
Re: RFC: Proposed updates to the Python Policy to reflect current practices
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 headingModule Package Names/heading p - Public modules should have a binary package named - packagepython-varfoo/var/package, - where varfoo/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 varpython-/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 + packagepython-varfoo/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
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Loïc Minier wrote: 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? Looks fine to me, but 3.1 needs to be updated too since it currently says that a package that needs `foo' must depend on `python-foo', which may not be correct anymore with this patch. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
* Loïc Minier l...@dooz.org, 2009-12-11, 12:34: url id=http://www.gnu.org/copyleft/gpl.html; - name=The GNU Public Licence. + name=The GNU Public License. That should read: The GNU General Public License. - explicitly use the versioned interpreter name + explicitly use the version-ed interpreter name Huh? versioned might not be recorded by dictionaries, but it is a common term in Debian-related documentation: $ zcat /usr/share/doc/debian-policy/*.txt.gz | grep -wc versioned 8 $ zcat /usr/share/doc/developers-reference/*.txt.gz | grep -wc versioned 4 Besides, version-ed is ugly as hell. -- Jakub Wilk signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote:
Looks fine to me, but 3.1 needs to be updated too since it currently says
that a
package that needs `foo' must depend on `python-foo', which may not be correct
anymore with this patch.
Ack
--
Loïc Minier
From ef9d6552930015aec0a9cb5a0b3d6bb5d2870f96 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 | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index c49957d..d9cf0dd 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -387,14 +387,21 @@
sect id=package_names
headingModule Package Names/heading
p
- Public modules should have a binary package named
- packagepython-varfoo/var/package,
- where varfoo/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 varpython-/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
+ packagepython-varfoo/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
@@ -536,7 +543,9 @@ XB-Python-Version: ${python:Versions}
/p
p
If the program needs the python module ttfoo/tt,
- it must depend on packagepython-foo/package.
+ it must depend on the real package providing this module, usually
+ packagepython-foo/package but this name might vary when the
+ package ships multiple modules.
/p
sect1 id=current_version_progs
--
1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Loïc Minier wrote: On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Looks fine to me, but 3.1 needs to be updated too since it currently says that a package that needs `foo' must depend on `python-foo', which may not be correct anymore with this patch. Ack Looks good, thanks! Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009 at 11:04:32AM +0100, Loïc Minier wrote: On Wed, Dec 09, 2009, Luca Falavigna wrote: I entirely read the 1.9.0.0 draft, I've got some thoughts on it. Thanks for your review, I'm attaching the following new patches: s/binary/interpreter for /usr/bin/python* I think this is a policy regression, actually. The fact that /usr/bin/python2.x is a binary, and /usr/bin/python is a symlink pointing to a binary, is not irrelevant - we certainly don't want someone to get the idea that it's ok to replace either of these with a script... So I would revert the first chunk, and for the second chunk change it to: @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loďc Minier Yes please! I'm struggling to read the patches like that I'd rather read git annotate =) which would be proposed final but with info where the words came from (patches or old stuff) Thanks. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Steve Langasek wrote: I think this is a policy regression, actually. The fact that /usr/bin/python2.x is a binary, and /usr/bin/python is a symlink pointing to a binary, is not irrelevant - we certainly don't want someone to get the idea that it's ok to replace either of these with a script... So I would revert the first chunk, and for the second chunk change it to: @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to Thanks, I merged something close; patch attached -- Loïc Minier From b4764801ece55036695e6d380ee5732986a0bf56 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org Date: Fri, 11 Dec 2009 10:13:52 +0100 Subject: [PATCH 26/30] Clarify which files are provided Clarify that pythonX.Y provides a /usr/bin/pythonX.Y interpreter binary and that python provides a /usr/bin/python symlink to the current pythonX.Y executable. --- debian/python-policy.sgml |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml index 804effc..7ba6a14 100644 --- a/debian/python-policy.sgml +++ b/debian/python-policy.sgml @@ -135,8 +135,9 @@ For every Python version provided in the distribution, the package packagepythonvarX/var.varY/var/package shall provide a complete distribution for emdeployment/em of Python scripts - and applications. The package must ensure that the binary - file/usr/bin/pythonvarX/var.varY/var/file is provided. + and applications. The package must ensure that the + file/usr/bin/pythonvarX/var.varY/var/file interpreter + executable is provided. /p p Installation of packagepythonvarX/var.varY/var/package @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to -- 1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Dmitrijs Ledkovs wrote: 2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loďc Minier Yes please! I'm struggling to read the patches like that I'd rather read git annotate =) which would be proposed final but with info where the words came from (patches or old stuff) Pushed as git.debian.org:~lool/public_git/python-defaults.git if you want to use ssh with an alioth account, or git://git.debian.org/~lool/python-defaults.git otherwise -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Le mardi 08 décembre 2009 à 21:24 +0100, Loïc Minier a écrit :
The goal of this set of patches is only to reflect what's de facto
being done in the archive, and update various bit-rotted sections of
the Python Policy. It's only a first step, but also a prerequisite for
other changes.
Indeed it starts looking like the current packaging practices in Python
packages.
As I already told you in private, I’d like to take this opportunity to
make a much necessary change to the policy: stop advising to use
Provides: ${python:Provides}.
Rationale: let’s consider a package foo that uses python2.4 directly
(with a python2.4 shebang), and depends on python2.4-foo, provided by
python-foo, which in turn depends on python-bar. If python-bar is
rebuilt with XS-P-V: = 2.5, it will stop providing python2.4-bar, but
python-foo will not change, and will still provide python2.4-foo. Then
foo will simply stop working.
This is why the usage of pythonX.Y-foo dependencies should not be
recommended. Packages providing public modules should all be in one of
these cases:
* No Provides: ${python:Provides} at all.
* The package has no dependency on other Python modules.
* The package depends on all pythonX.Y-bar, for X.Y in
${python:Versions} and bar in all dependencies in other modules.
Since the last solution is very suboptimal (it requires simultaneous
uploads and testing migration for all entangled packages), it should be
avoided – and anyway we should discourage use of a specific pythonX.Y
version.
Another related issue is that of packages linking to libpython to embed
an interpreter. Most of them link to the library corresponding to the
default python version of the moment. Therefore all their dependencies
should be pythonX.Y-foo and not python-foo like what is (incorrectly)
done currently.
Maybe we should find a way to make python-support add the correct
pythonX.Y-foo dependencies instead. Of course, this makes those packages
jump right into the issue I explained before. Another possibility is to
generate python (= X.Y), python ( X.Y+1) in this case, but it is
precisely the kind of ideas that make transitions a nightmare.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Il giorno Tue, 8 Dec 2009 21:24:05 +0100
Loïc Minier l...@dooz.org ha scritto:
To resurrect the Python Policy as a document reflecting required and
recommended Python packaging practices, we prepared a set of patches.
Many thanks for that!
I entirely read the 1.9.0.0 draft, I've got some thoughts on it.
---
| 1.2. Main packages
|
|At any time, the `python' package must ensure that the binary
|`/usr/bin/python' is provided.
---
This is currently not a binary, but a relative symlink pointing
to ./pythonX.Y (where X.Y is the current supported Python version).
Should this point be reworded to avoid confusion?
---
| 1.5. Module Path
|
|As an exception to the above, modules managed by python-support are
|installed in another directory which is added to the sys.path using
|the .pth mechanism.
---
I'm unsure about this point. Doesn't python-support search for modules
in /usr/lib/pythonY.X/{site,dist}-packages, or is this another location
where pysupport can look at?
---
| 2.2. Module Package Names
|
|Public modules should be packaged with a name of `python-foo',
|where foo is the name of the module.
---
Since this can lead to some misunderstandings, I'd add that this
naming scheme applies to binary packages, things are relaxed speaking
of source package names, where we usually conform to upstream names.
---
| 2.3. Specifying Supported Versions
|
|Your control file should also have a line:
|
| XB-Python-Version: ${python:Versions}
|
|The python:Versions is substituted by the supported Python
|versions of the binary package, based on `XS-Python-Version'. (If
|you are not using python-central or python-support, you will need
|to handle this substitution yourself.)
---
python-support doesn't manage XB-Python-Version (or at least it
shouldn't right now). Is this supposed to be changed in python-support,
or packages using such tool can ignore it?
---
| 3.1. Programs using the default python
|
|If the program needs the python module `foo', it must depend on
|`python-foo'.
---
This is conflicting with 2.2: it has been told packages providing foo
module *should* be named as python-foo, while here it has been told
programs needing foo module *must* depend on python-foo, which could
eventually follow another naming scheme. I think we should strictly
enforce 2.2, or relax 3.1.
It looks fine to me otherwise, thanks again!
--
.''`.
: :' : Luca Falavigna dktrkr...@debian.org
`. `'
`-
signature.asc
Description: PGP signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Tue, Dec 08, 2009 at 09:24:05PM +0100, Loïc Minier wrote: To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. We started in private to provide a complete set of changes and avoid flames as much as possible, but now we'd like the whole Debian Python community to send comments, feedback, or additional patches. The goal of this set of patches is only to reflect what's de facto being done in the archive, and update various bit-rotted sections of the Python Policy. It's only a first step, but also a prerequisite for other changes. Hi! From what I can see, the current document seems to codify what seems to be happening already. I've read through the document, and, with my limited understanding of the procedures involved, I would guess that the document is now in sync with the current, albeit unwritten, standards followed in Python packages. Naturally, someone who knows more than me voice their opinions/concerns. I was wondering what the subsequent steps have in store, and what the likely changes you propose would involve. If I'd have to wait and watch, that would be fine. Thank you for working on this. Kumar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Hello, Now I wish I could find time to write de-facto packaging tutorial in wiki to see how the patched policy and original policy is going to solve this real-world problem. Thanks for collaboration. -- anatoly t. On Tue, Dec 8, 2009 at 10:24 PM, Loïc Minier l...@dooz.org wrote: [ MFT: debian-pyt...@ldo ] Hi all, To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. We started in private to provide a complete set of changes and avoid flames as much as possible, but now we'd like the whole Debian Python community to send comments, feedback, or additional patches. The goal of this set of patches is only to reflect what's de facto being done in the archive, and update various bit-rotted sections of the Python Policy. It's only a first step, but also a prerequisite for other changes. We hope that once consensus is reached on how to fix the Python Policy in the python-defaults package, we can propose new series of patches proposing changes to the Python Policy such as ideas from the new dh_python proposal [1], or Python 3.x support etc. Thanks, [1] http://lists.debian.org/debian-python/2009/08/msg3.html -- Piotr Ożarowski, Scott Kitterman, Loïc Minier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkseteUACgkQ4VUX8isJIMD7YQCeIyGvxjxjg0nfsC+xcvJaBpiE ohAAnR4BarvnITsGUeJYyAAvnTcQCG/d =hlfn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Luca Falavigna dktrkr...@debian.org writes: --- | 1.2. Main packages | |At any time, the `python' package must ensure that the binary |`/usr/bin/python' is provided. --- This is currently not a binary, but a relative symlink pointing to ./pythonX.Y (where X.Y is the current supported Python version). It seems to be common practice to use the term “binary” for things that often aren't binaries, but merely lead to a program being run. You're right that it's confusing. Should this point be reworded to avoid confusion? Yes, I think this would be clearer as “program”. I have no problem with leaving it unstated that it may be a symlink to another file. --- | 2.2. Module Package Names | |Public modules should be packaged with a name of `python-foo', |where foo is the name of the module. --- Since this can lead to some misunderstandings, I'd add that this naming scheme applies to binary packages, things are relaxed speaking of source package names, where we usually conform to upstream names. I would also prefer to avoid ambiguity with the separate Python concept of “package”. Perhaps: Public Python packages or modules should be packaged with a Debian package name of ‘python-foo’, where foo is the name of the Python package or module as used in the ‘import’ statement. --- | 3.1. Programs using the default python | |If the program needs the python module `foo', it must depend on |`python-foo'. --- s/python module/Python module or package/ This is conflicting with 2.2: it has been told packages providing foo module *should* be named as python-foo, while here it has been told programs needing foo module *must* depend on python-foo, which could eventually follow another naming scheme. I think we should strictly enforce 2.2, or relax 3.1. Right. This doesn't distinguish “needs a module” from “needs a public, third-party module”, I think it should. -- \ “The most common way people give up their power is by thinking | `\ they don't have any.” —Alice Walker | _o__) | Ben Finney pgpXiov149A9d.pgp Description: PGP signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
* Loïc Minier l...@dooz.org, 2009-12-08, 21:24: + versions explicitely. You could fix that typo if you are at it. (Sorry for nitpicking!) -- Jakub Wilk signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
2009/12/8 Loïc Minier l...@dooz.org: [ MFT: debian-pyt...@ldo ] Hi all, To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. We started in private to provide a complete set of changes and avoid flames as much as possible, but now we'd like the whole Debian Python community to send comments, feedback, or additional patches. Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
Dmitrijs Ledkovs dmitrij.led...@gmail.com (09/12/2009): Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? $ debcheckout debian-policy declared git repository at git://git.debian.org/git/dbnpolicy/policy.git git clone git://git.debian.org/git/dbnpolicy/policy.git debian-policy ... Initialized empty Git repository in /tmp/debian-policy/.git/ […] Mraw, KiBi. signature.asc Description: Digital signature
