Hello Zooko On Wed, Jan 28, 2009 at 07:44:04AM -0700, zooko wrote: > On Jan 28, 2009, at 3:45 AM, David Cournapeau wrote: > >>> I don't understand what are the potential problems, but so far I've >>> been happy using stdeb to produce .deb's from my Python sdists. >> >> This is not the right solution for distributions maintainers: it is a >> good tool for individual (it gives you uninstallation, etec...) but >> .deb packages produced by stddeb are not debian-compatible, and cannot >> be included in debian proper. This is not a critic of stddeb, I think >> it is a very good tool and useful tool. > > I've heard things like this from Debian developers before, and I don't > understand. Please provide me with more explanation.
The answer (or the part that comes to my mind at this moment at least) is: Policy, Policy and Policy. Debian is so good in no small part because each package has to follow the Policy (and all applicable sub-policies). * I don't trust a random python developer who might never even have heard of Debian to pick the correct name of their python project that will ensure the resulting package name will be correct and not conflict. * I know for a fact that distutils capabilities are not good enough to fully automatically follow the FHS (discussed many a times on this list already). * setup.py allows for arbitrary code to be executed, if you don't know the proper distutils way to do something you can make it do it in many different ways. These will break assumptions automated tools will make. * <more variations on the same themes here> > I don't intend to > put words in your mouth, but I will offer a few guesses as to why you say > stddeb can't be used for Debian proper: This is pretty much flamebait but I'll answer anyway, again it boils down to the above points though. > 1. You want the production of .deb's from Python packages to be done by > a human instead of automatedly, therefore stdeb can't do it. Yes, currently distutils is just not good enough. Maybe if the tools (including distutils) improve this could be wittled down to just checking setup.py (or equivalent) declares everything properly before letting the automated tools loose. > 2. You want the production of .deb's from Python packages to be done by > a Debian developer instead of by the upstream developer of the Python > package. Yes, someone who cares about the Debian Policy. > 3. It would be okay for this process to be automated (or semi- > automated), but there's some flaw in the design of stdeb which means it > will never be able to do it right unless stdeb is rewritten with a new > design. I have no idea about stdeb as I've never used it, but distutils just doesn't provide enough information as I mentioned earlier. So yes. > 4. It would be okay, and the general design of stdeb is okay, but there > are some bugs in stdeb which currently cause it to produce the wrong > results. Ugh, really repeating things by now. But for a change I'll go for "no" as this is simply not applicable. There are probably many more reasons that I'm not thinking off right now. Most of those can probably be found sprayed around in various long threads on this list. IIRC Josselin Mouette did once summarise Debian's issues quite decently on this list. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
