Marc Dequènes wrote: > As you may have heard, Python packaging is moving fast these days. We > plan the move the current Python version to 2.4 and in the same time > are drafting a new policy and creating new tools to greatly improve > the current situation. All this leads to the need for a newer class, > which will at the end replace the current one completly.
Thank you for working on this. I haven't tested this yet at all, but I have a couple of small concerns about your proposal: - 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. :-) - DEB_PYTHON_MODULE_PACKAGE should perhaps default to the package that matches python-* in addition to the other criteria? - 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. 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? 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
