Re: Request to join python-modules team
Hi, On Wed, 14 Jun 2006, Simon McVittie wrote: > Hi, > I'd like to join the python-modules team, in order to co-maintain > python-docutils with Martin F. Krafft. My Alioth login is smcv-guest. Welcome to the group! You have been added, you will have commit rights tomorrow. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python distutils class
On Wed, 14 Jun 2006, Marc Dequènes wrote: > > - Perhaps in keeping with the style of cdbs, it would be better to have > > two classes python-pycentral and python-pysupport (and some > > python-common or python-core) behind it? This would also avoid the > > tacky use of -ng in the class name. :-) > > buxy replied to this. I would add by having a method selector we can in > the end remove the obsoleted method when this comes, as nothing else > (from a user point of view) is method-specific. Agreed. > > - DEB_PYTHON_MODULE_PACKAGE should perhaps default to the package that > > matches python-* in addition to the other criteria? > > As python package don't have to match python-* in all cases (apps > don't), i conclude this is wrong in such cases, and superflous in other > ones. With no comment from people on IRC when i asked, i decided to > leave this untouched. Can most python applications be installed with distutils? (i.e. I'm not sure that the class is going to be really used for python applications) > In needed_tools/ you'll find the corresponding cdbs package i intend to > upload if you have no objection (or you may upload it yourself if you > prefer). You have right problems on the source package (403 forbidden). I would love to have this upload to happen today before dinstall (19:00 UTC) as we have many python packages relying on CDBS in the team. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 08:38:57PM +0200, Raphael Hertzog wrote: > the Python team has agreed on a new policy [1]. As we want to do the > python 2.4 transition now, we need to make sure the packages match the > policy. This will limit the amount of broken packages when python2.4 will > become the default and will smooth this transition. > > So please check in the list at the end of this mail if you're concerned, > and if yes, please update your packages following these instructions: > http://wiki.debian.org/DebianPython/NewPolicy > http://people.debian.org/~piman/python-policy/ > > If you don't have time to do this now, please reply on > debian-python@lists.debian.org and allow us to make NMU of your packages. > You could also take this opportunity to start maintaining the packages > within the team, see http://python-modules.alioth.debian.org/. We'll > gladly add you to the team, just request it on the mailing list. My libgpod package didn't appear in the list because it currently only builds an python2.3-gpod and no python-gpod at all. Feel free to NMU this package as I really have no idea about that whole python modules stuff (I only applied a user-supplied patch to generate the .deb named above) and not much time either. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 09:13:26PM +0200, Mike Hommey wrote: > PS: Anyways, there's one package you didn't list because it's in NEW, > which WON'T be merged as required by the new policy: python2.x-xpcom, > provided by xulrunner. > The reason is simple: different installations for different python > versions CAN'T coexist without breaking each other. Can you expand on this? As Joe commented, it sounds fairly broken for these packages to not be coinstallable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#370833: New dh_python proposal
Joey Hess writes: > I don't particularly mind that you've chosen to NMU debhelper. However, > I can't guarantee that I will preserve the interfaces that you've added > to dh_python in a backwards compatible way when I get around to looking > at it. > > (FWIW, I began ignoring this issue when the politics and constant > advocacy and pressure became too annoying to bother with, and I expect > to ignore it for at least another couple of weeks. Unfortunatly that > means that to avoid either trampeling over or blessing your NMU, I won't > be able to release any other debhelper fixes in that timeframe either.) could you agree in temporarily/permanently splitting out dh_python from debhelper? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Request to join python-modules team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to join the python-modules team, in order to co-maintain python-docutils with Martin F. Krafft. My Alioth login is smcv-guest. I'm currently preparing an upload which will fix some of the old bugs and use the new Python policy. Thanks, Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFEj0R1WSc8zVUw7HYRAiuSAKCbGqPLLscTO2qFLqjp2XIEealwuwCgyRCx H6NGtwVN5cPF77HiTR7W8eg= =KCfR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New python distutils class
Coin, Peter Eisentraut <[EMAIL PROTECTED]> writes: > - Perhaps in keeping with the style of cdbs, it would be better to have > two classes python-pycentral and python-pysupport (and some > python-common or python-core) behind it? This would also avoid the > tacky use of -ng in the class name. :-) buxy replied to this. I would add by having a method selector we can in the end remove the obsoleted method when this comes, as nothing else (from a user point of view) is method-specific. > - DEB_PYTHON_MODULE_PACKAGE should perhaps default to the package that > matches python-* in addition to the other criteria? As python package don't have to match python-* in all cases (apps don't), i conclude this is wrong in such cases, and superflous in other ones. With no comment from people on IRC when i asked, i decided to leave this untouched. > Btw., before this can be uploaded, it would be good if some of these > build dependencies existed first, so a test case can be written. They all are available in unstable now. You can find in my web directory 2 examples (soya and editobj), where, besides bugs in pysupport or pycentral, are well built using an updated version of the class : http://perso.duckcorp.org/duck/python-new-policy/ buxy also tested 3 packages : http://people.debian.org/~hertzog/python/examples/ In needed_tools/ you'll find the corresponding cdbs package i intend to upload if you have no objection (or you may upload it yourself if you prefer). But please be quick, we are close to the release team deadline. -- Marc Dequènes (Duck) pgpGd1ZZZg6gd.pgp Description: PGP signature
Re: Coordinated effort to update python packages
Mike Hommey writes: > On Tue, Jun 13, 2006 at 09:55:08PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> > wrote: > > When you install some python extensions (.so), it is common that they come > > with > > associated .py files (modules). Those .py files usually are the same in > > /usr/lib/python2.3 and /usr/lib/python2.4, that's why python-central will > > keep only one copy of them in /usr/share/pycentral and symlink them back > > into > > /usr/lib/python2.[34]/ ... > > > > However if the .py installed in /usr/lib/python2.3 is different from the > > one installed in /usr/lib/python2.4, then you can't share it between both > > versions (and you need the DH_PYCENTRAL="nomove" variable). That what's I > > meant. Feel free to fix the wording in the wiki if you have a better way > > to express it. > > Okay, it sounds clearer said like that. Stupid question: why doesn't > pycentral autodetect if files are different or not ? I don't actually > see a reason why DH_PYCENTRAL need to be set... python-tk and python-gdbm include the -tk and -gdbm versions from both python2.3 and 2.4, so that we are able to ship them in one package. In that case, these must be installed in /usr/lib/python. Just moving the identical files becomes a bit complex; it is handled by pycentral, but not by dh_pycentral, so you have to move them yourself. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
Graham Wilson writes: > On Tue, Jun 13, 2006 at 11:22:27PM +0200, Piotr Ozarowski wrote: > > Graham Wilson ([EMAIL PROTECTED]): > > > Speaking of this, I have a module (python-pyx) that I think is only used > > > by end-users (not applications), so I think it makes sense to only > > > install modules and extensions for the current version. Does this make > > > sense? > > > > What if default python version will change? You will have to reupload > > your package. > > That would happen anyway for new Python releases, plus, my understanding > is that with the new Python framework in place, supporting new Python > versions can be handled simply by bin NMUs in the case that I can't make > an upload myself. that is correct. OTOH, each new upload to unstable may add a new dependency on a newly uploaded library having a more strict dependency or a new soname. If you build for the version we transition from, and for the version we transition to, we even don't need that binNMU anymore. Once the python change did migrate to testing and we drop support for the old supported python version, you can binNMU the package. So you should provide extensions not only for the default version, - if you depend on shared libaries which take long to migrate to testing - the extension is required as a dependency for a package not using the default python version. One other side effect: If we include python2.5 in the set of supported versions in an upload to experimental, we can easily check all packages for python2.5 compatibility (building at least). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
Graham Wilson ([EMAIL PROTECTED]): > On Tue, Jun 13, 2006 at 11:22:27PM +0200, Piotr Ozarowski wrote: > > What if default python version will change? You will have to reupload > > your package. > > That would happen anyway for new Python releases, plus, my understanding > is that with the new Python framework in place, supporting new Python > versions can be handled simply by bin NMUs in the case that I can't make > an upload myself. What if user will change his default python version (f.e. if his scripts will use /usr/bin/env python, or simply he will start his script with pythonX.Y)? -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpFAC2ID0f0t.pgp Description: PGP signature
Re: Coordinated effort to update python packages
Le mardi 13 juin 2006 à 16:31 -0500, Graham Wilson a écrit : > That would happen anyway for new Python releases, plus, my understanding > is that with the new Python framework in place, supporting new Python > versions can be handled simply by bin NMUs in the case that I can't make > an upload myself. This is nothing new. This is already the case for all packages using dh_python. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 11:22:27PM +0200, Piotr Ozarowski wrote: > Graham Wilson ([EMAIL PROTECTED]): > > Speaking of this, I have a module (python-pyx) that I think is only used > > by end-users (not applications), so I think it makes sense to only > > install modules and extensions for the current version. Does this make > > sense? > > What if default python version will change? You will have to reupload > your package. That would happen anyway for new Python releases, plus, my understanding is that with the new Python framework in place, supporting new Python versions can be handled simply by bin NMUs in the case that I can't make an upload myself. -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
Graham Wilson ([EMAIL PROTECTED]): > Speaking of this, I have a module (python-pyx) that I think is only used > by end-users (not applications), so I think it makes sense to only > install modules and extensions for the current version. Does this make > sense? What if default python version will change? You will have to reupload your package. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp8URMDc0ZFZ.pgp Description: PGP signature
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 09:55:08PM +0200, Raphael Hertzog wrote: > OK, then indicate "current" in XS-Python-Version and support only the > current version in python-xpcom (make sure to generate the provides > field). Speaking of this, I have a module (python-pyx) that I think is only used by end-users (not applications), so I think it makes sense to only install modules and extensions for the current version. Does this make sense? -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, 2006-06-13 at 22:05 +0200, Mike Hommey wrote: > On Tue, Jun 13, 2006 at 09:55:08PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> > wrote: > > When you install some python extensions (.so), it is common that they come > > with > > associated .py files (modules). Those .py files usually are the same in > > /usr/lib/python2.3 and /usr/lib/python2.4, that's why python-central will > > keep only one copy of them in /usr/share/pycentral and symlink them back > > into > > /usr/lib/python2.[34]/ ... > > > > However if the .py installed in /usr/lib/python2.3 is different from the > > one installed in /usr/lib/python2.4, then you can't share it between both > > versions (and you need the DH_PYCENTRAL="nomove" variable). That what's I > > meant. Feel free to fix the wording in the wiki if you have a better way > > to express it. > > Okay, it sounds clearer said like that. Stupid question: why doesn't > pycentral autodetect if files are different or not ? I don't actually > see a reason why DH_PYCENTRAL need to be set... > > > > PS: Anyways, there's one package you didn't list because it's in NEW, > > > which WON'T be merged as required by the new policy: python2.x-xpcom, > > > provided by xulrunner. > > > The reason is simple: different installations for different python > > > versions CAN'T coexist without breaking each other. > > > > OK, then indicate "current" in XS-Python-Version and support only the > > current version in python-xpcom (make sure to generate the provides > > field). > > What about people who want to use pyxpcom with modules that aren't > available with the current python ? But a user couldn't install more than one such module at a time, since the packages are mutually exclusive. It seems far better to me to just force everyone to use one version and avoid the issue. Or, fix pyxpcom, which sounds horribly broken. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 09:55:08PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > When you install some python extensions (.so), it is common that they come > with > associated .py files (modules). Those .py files usually are the same in > /usr/lib/python2.3 and /usr/lib/python2.4, that's why python-central will > keep only one copy of them in /usr/share/pycentral and symlink them back into > /usr/lib/python2.[34]/ ... > > However if the .py installed in /usr/lib/python2.3 is different from the > one installed in /usr/lib/python2.4, then you can't share it between both > versions (and you need the DH_PYCENTRAL="nomove" variable). That what's I > meant. Feel free to fix the wording in the wiki if you have a better way > to express it. Okay, it sounds clearer said like that. Stupid question: why doesn't pycentral autodetect if files are different or not ? I don't actually see a reason why DH_PYCENTRAL need to be set... > > PS: Anyways, there's one package you didn't list because it's in NEW, > > which WON'T be merged as required by the new policy: python2.x-xpcom, > > provided by xulrunner. > > The reason is simple: different installations for different python > > versions CAN'T coexist without breaking each other. > > OK, then indicate "current" in XS-Python-Version and support only the > current version in python-xpcom (make sure to generate the provides > field). What about people who want to use pyxpcom with modules that aren't available with the current python ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, 13 Jun 2006, Mike Hommey wrote: > > So please check in the list at the end of this mail if you're concerned, > > and if yes, please update your packages following these instructions: > > http://wiki.debian.org/DebianPython/NewPolicy > > http://people.debian.org/~piman/python-policy/ > > Maybe I'm dumb or something, but I don't get what > "If the public modules installed differ between python versions and if > they can't be shared, you should set the following environment variable > when invoking dh_pycentral." > is supposed to mean. When you install some python extensions (.so), it is common that they come with associated .py files (modules). Those .py files usually are the same in /usr/lib/python2.3 and /usr/lib/python2.4, that's why python-central will keep only one copy of them in /usr/share/pycentral and symlink them back into /usr/lib/python2.[34]/ ... However if the .py installed in /usr/lib/python2.3 is different from the one installed in /usr/lib/python2.4, then you can't share it between both versions (and you need the DH_PYCENTRAL="nomove" variable). That what's I meant. Feel free to fix the wording in the wiki if you have a better way to express it. > PS: Anyways, there's one package you didn't list because it's in NEW, > which WON'T be merged as required by the new policy: python2.x-xpcom, > provided by xulrunner. > The reason is simple: different installations for different python > versions CAN'T coexist without breaking each other. OK, then indicate "current" in XS-Python-Version and support only the current version in python-xpcom (make sure to generate the provides field). > PPS: I'll take care of libxml2 and libxslt as soon as I understand what > I'm supposed to change. Feel free to ask other questions if needed. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#370833: New dh_python proposal
Le mardi 13 juin 2006 à 15:23 -0400, Joey Hess a écrit : > (FWIW, I began ignoring this issue when the politics and constant > advocacy and pressure became too annoying to bother with, and I expect > to ignore it for at least another couple of weeks. Unfortunatly that > means that to avoid either trampeling over or blessing your NMU, I won't > be able to release any other debhelper fixes in that timeframe either.) If it is really slowing things down this way, I will ask for the removal of python-support. Although it is a better and simpler solution than python-central, I don't want to delay the move to python2.4 several more month. We've already waited too much for Matthias to start moving. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Coordinated effort to update python packages
* Mike Hommey ([EMAIL PROTECTED]) [060613 21:29]: > PPS: I'll take care of libxml2 and libxslt as soon as I understand what > I'm supposed to change. Please don't upload libxml2 until the current version either hits testing or is RC-buggy. Thanks. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coordinated effort to update python packages
On Tue, Jun 13, 2006 at 08:38:57PM +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > Hello, > > the Python team has agreed on a new policy [1]. As we want to do the > python 2.4 transition now, we need to make sure the packages match the > policy. This will limit the amount of broken packages when python2.4 will > become the default and will smooth this transition. > > So please check in the list at the end of this mail if you're concerned, > and if yes, please update your packages following these instructions: > http://wiki.debian.org/DebianPython/NewPolicy > http://people.debian.org/~piman/python-policy/ Maybe I'm dumb or something, but I don't get what "If the public modules installed differ between python versions and if they can't be shared, you should set the following environment variable when invoking dh_pycentral." is supposed to mean. Please Cc: me, I'm not subscribed. Mike PS: Anyways, there's one package you didn't list because it's in NEW, which WON'T be merged as required by the new policy: python2.x-xpcom, provided by xulrunner. The reason is simple: different installations for different python versions CAN'T coexist without breaking each other. PPS: I'll take care of libxml2 and libxslt as soon as I understand what I'm supposed to change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#370833: New dh_python proposal
I don't particularly mind that you've chosen to NMU debhelper. However, I can't guarantee that I will preserve the interfaces that you've added to dh_python in a backwards compatible way when I get around to looking at it. (FWIW, I began ignoring this issue when the politics and constant advocacy and pressure became too annoying to bother with, and I expect to ignore it for at least another couple of weeks. Unfortunatly that means that to avoid either trampeling over or blessing your NMU, I won't be able to release any other debhelper fixes in that timeframe either.) -- see shy jo signature.asc Description: Digital signature
Re: Instructions to update a package for the new python policy
On Tue, 13 Jun 2006, Raphael Hertzog wrote:
> Hi,
>
> I've prepared this:
> http://wiki.debian.org/DebianPython/NewPolicy
>
> Feel free to enhance.
>
> I also converted python-pam as an example (std debhelper package):
> http://people.debian.org/~hertzog/python/examples/
>
> I'll gladly put other examples packages at the same place. Just send them
> to me.
>
> Now it's time to ask all maintainers to update their packages. Someone
> should prepare several list of source packages:
> - python extensions
> - python modules only
> - python apps
I left python apps on the side for now.
Here's a list of sources packages that need to be updated (266 packages):
http://people.debian.org/~hertzog/python/sources-by-maint
In that list, those are "arch: any" (137 packages, extensions mainly, but
there are false positives so beware):
http://people.debian.org/~hertzog/python/sources-any-by-maint
And here are the "arch: all" (127 packages):
http://people.debian.org/~hertzog/python/sources-all-by-maint
I generated the list with this perl command line:
$ perl -e '$/="";foreach (grep { /^Binary: .*\bpython-/m &&
(!/^Python-Version:/m) } (<>)) { /^Package: (.*)$/m && print "$1\n" }'
/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_source_Sources
>sources
(and then through dd-list --stdin)
It looks for source packages generating a "python-*" binary package and
which do not have a Python-Version header.
I will post that list to debian-devel-announce asking people to update
their packages and warning them that bugs will be opened with very short
NMU delay.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Instructions to update a package for the new python policy
On Tue, 13 Jun 2006, Raphael Hertzog wrote: > Now it's time to ask all maintainers to update their packages. Someone > should prepare several list of source packages: > - python extensions > - python modules only > - python apps > > Then we need to fill bugs, and usertag them "policy-ext", "policy-mod" and > "policy-apps" with identity "debian-python@lists.debian.org" to be able to > follow the progress here: > http://bugs.debian.org/usertag:debian-python@lists.debian.org BTW, if anyone is doing that, please propose to the maintainers to join the team and co-maintain their packages with us. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: installing modules and extensions in packages (python sense) in separate directories
Le samedi 10 juin 2006 à 16:24 +0200, Matthias Klose a écrit : > As pointed out in [1], the split of a package (in the python sense) > with extensions and modules into two different directories leads to > a changed import order and should be avoided. I.e. this kind of > package must be installed into one place. > > Looking at python-support I can only see one possibilty to package > this kind of package, duplicating all files for all supported python > versions in /usr/lib/python2.X, significantly increasing the package > size. Is there another way to support this or is this the only option? I intend to separate the .so files in /usr/lib/python-support/$package/python2.x and to link them in /var/lib/python-support/python2.x together with the .py files from /usr/share/python-support. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: New python distutils class
On Tue, 13 Jun 2006, Peter Eisentraut wrote: > - The appearance of the DEB_PYTHON_PRIVATE_MODULES_DIRS variable seems > to be unrelated to this change. I don't doubt it might be useful, but > I just want to be sure where it's coming from. Well, it's kind of unrelated since the old dh_python can also benefit from it... but it's really needed now since packages with private modules will have to supply it from now on. > At the risk of reopening a flame war, what is the point of supporting > two build systems? I can understand that when you write your rules > file by hand, one system or the other may be more convenient in a > particular situation. But when cdbs runs things, it seems to make no > difference to the users, so why should they be burdened with this > choice? The CDBS users of this class are the python maintainers, and since there's no consensus yet on the right tool, we want to offer the choice... :-) > Btw., before this can be uploaded, it would be good if some of these > build dependencies existed first, so a test case can be written. They exist, they are in unstable as of today. And we have lots of python modules using CDBS to update, so it would be great if Marc can finish his class today and if you can upload a new version quickly afterwards. :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
