On Thu, Aug 24, 2006 at 11:46:25PM +0200, Josselin Mouette wrote: > Let me rephrase it: the internals of python-support, and how it helps > implementing the python policy, are developed in the python-support > documentation. They don't need to be part of the policy
Yes they do. > and they have nothing to do with debhelper either. That's good, but not enough. > > This has now been going on for long enough that I conclude that the > > Python policy pushers really do intend to make using debhelper a Policy > > requirement for any package containing any Python code. > > I can't speak for others, but python-support provides > pysupport-movemodules and pysupport-parseversions to separate the > debhelper snippet from the actual abstraction code. That is still not what is required. Unless these tools become part of the dpkg-dev package, it should be documented in policy how they (are supposed to) do their job. Sure, you're free to seriously discourage people not to use these tools; but the assumption that it is possible to create a Debian package by just copying the right files to the right place and calling 'dpkg -b' on that has always been true. It would be wrong to change this assumption. > (BTW, for a similar problematic that involves more than a hundred > packages, nobody ever asked me how to make a package using GConf without > using dh_gconf. Which means the GConf policy has never been written out > but is currently defined by the dh_gconf behavior.) The mere fact that a given bug exists somewhere else, too, does not make it less of a bug. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
