Tarek Ziadé wrote:
Well, as long as things are clearly defined in the package, I guess FHS compliant package could be built with the same source tree.
We could even install a distribution the FHS way or the self-contained way, as long as the tool knows what to put where.
Yes, in theory, it is easy: just set which kind of files are put where, like e.g. autotools (datadir, libdir, etc...). In practice, I am not sure it will so easy, because distutils is so badly "designed". It breaks in so many cases, because you never know what is part of the specification and what is not. Will you break something if you change a given directory ? You can't know, and testing on one platform is not enough because distutils authors thought it was a great idea to dynamically defined most attributes of most classes, with the consequence that some attributes exist in some cases only, on some platforms only.
But that is already the case, a bit: For instance we have bdist_rpm, that builds rpms by mapping distutils metadata to rpm ones,
You can't be general when talking about distutils. All the pain come from implementation details and undocumented features. I could spend one hour listing all the sillyness in distutils, none of them being present in any other build system I have ever encountered. Again, other people know distutils much better than me and may disagree with me, or maybe rightfully notice my lack of experience on that codebase, but from my own work on it - which while not complicated was not trivial either - I got the conviction that any fundamental change wrt distutils will be extremely painful to do if not impossible in a backward compatible way. I was hoping that a distutils replacement would come for Py3k, actually :) cheers, David