Floris Bruynooghe wrote:
Hmm fair enough, I must have missed that last time I looked at the implementation of python-support and python-central. But both take the burden of having to create a symlink farm because of this though. And to be honest I think the motivation for this is supporting multiple python versions without having to duplicate all .py files rather then the FHS.
Yes, multiple-versions certainly motivated the split as well. I think Fedora Core for example does not support multiple python versions (I can't find a reference ATM), but I am not a user of rpm-based distributions, so don't really know much about it and how they do it.
But the great thing about the proposal is that it doesn't even matter. Files will be easily tagged/detected as "python modules" and "python extension modules" and the tools consuming this information can decide to do what they want with them.
exactly. FHS is just one example - I suggested following autoconf categories because that's the maximum flexibility, and can be used for many cases, since it is a defacto standard (on Unix at least - but I don't think we need to change much how things are done for Mac OS X and Windows). cheers, David