Phillip J. Eby writes: > Unfortunately, Debian's policy -- especially the idea of mixing paths for > multiple Python versions -- doesn't mesh well with reality.
that's a misunderstading, we don't do that. common files are shipped in one location outside of sys.path and linked to a version specific location inside sys.path for every python version. > Python > projects don't always install the same files for a given Python version, or > the same content in the same files. Setuptools is only a relatively minor > example of this; other Python projects do far more customization of the > install process (by Python version and dependencies) than setuptools does > of its own. Bluntly, mixing Python versions on the same path for > *installed* packages (whether installed by the distutils or setuptools) > borders on insanity. again, they are not mixed. I didn't see that many packages with different files between Python versions. could you give some examples? > (More precisely, it sounds like exactly the sort of thing to do if one > wanted to create all sorts of problems for which one could then claim > credit for fixing as part of a "quality assurance" effort, constantly > patching upstream packages to work around the problems, thereby cementing > in one's own mind the importance of doing QA work to fix those upstream > authors' shoddy work that fails to live up to your distribution's "quality" > standards. And yet somehow, nobody will ever seem to notice that it's the > policy *itself* that's causing the problems, because of *course* those > upstream developers know *nothing* about quality assurance... sigh. But > that's a rant for another day.) I don't see the problem you describe. But anyway, doing QA work in Debian for python packages (related to the pakage itself) is - to move around files into FHS conforming locations in the file system (in contrast to the Windows centric view of many upstream modules / packages installing a thing in _one_ location) and keep the package working. FHS is not just a quality standard for Debian. - remove included third party modules and depend on the modules instead which are shipped in the distribution (removed three copies of pytz in the last months). Maybe it's the desire of upstream authors to provide a complete one-click-setup lacking a decent package management system for other platforms, but it should be an option, not the default. - remove files which do not conform to the Debian Free Software Guidelines (DFSG), which would disallow the distribution of an upstream package in Debian. - Fix window'isms like linking extension modules with libpython, convert file encodings, etc. - add exact meta information (dependencies) that allows upgrades, even partial ones, between distribution releases. It would be nice to use upstream meta information, without relying on a newly invented dependency tracking system which doesn't integrate well with existing packaging systems. I think the PEP trying to get this information into the meta-data was rejected as over-specified. - split an upstream package into more than one binary package to avoid unnecessary installations (i.e. install the python-imaging parts, which do not depend on X or Sane). The policy addresses other (Debian related) things like not introducing new debian package names for new python versions (because that requires interaction by FTP adminstrators) and avoiding uploads for every python package when the python version changes and hindering the release process for the distribution (forcing big-bang updates between the unstable and the testing release). So yes, I don't expect upstream authors to know anything about Debian QA and to adjust the packaging instead as a package maintainer. Non-Debian specific changes are usually forwarded to the upstream authors. Upstreams aren't a homogenous group, from some authors I get immediate feedback if I modify something in the package, others don't see a a need to fix a "python setup.py clean" removing half of the distributed files which cannot be regenerated. Matthias _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
