-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Oussoren wrote:
> On 6-aug-2006, at 19:49, Phillip J. Eby wrote: >> Of course, since it is such a useful and sensible idea, it will of >> course be incompatible with Debian Python policy. > > This one is worse, it is incompatible with the packaging policy of > every Linux distribution, header files must be in -devel packages > obviously :-(. Maybe --single-version-externally-managed should just > revert to the current "let's install the header in the python headers > directory" behaviour, that way you won't get the wrath of the Debian > packagers while "real" eggs behave as they should. > >> Sadly, that isn't a joke, as I'm sure there will be screams of >> bloody murder regarding the idea of putting headers inside >> directories inside Python version-specific library directories, not >> the least since they will want to split such packages into a plain >> and "devel" version. > > I know, this can be very annoying and seems to be one of the most > asked questions on this list (or rather, "how do I install distutils > manually?"). > >> There will then be much wailing and gnashing of teeth by people >> trying to develop SVN-based packages atop Debian, since setuptools >> will notice the presence of the Debian-installed packages and try >> to use their (missing) header files when the user attempts to build >> something. >> >> The Debian team will see nothing wrong with this because obviously >> the user should've known by osmosis that a -devel package was >> needed, and... [sigh] > > The end result of which may will be that a meme will spread that says > you shouldn't use the distributors build of python because that is > broken. That meme is already prevalent in the Zope world: the tradeoffs the distro authors make when packaging Python (e.g., using UCS4 because it supposedly makes for a better GUI experience, or putting distutils et. aliae into a separate, not-installed-by-default package) serve goals which are not compatible with those of the long-running appserver. > I don't envy you here, at least some people that try to build > their own eggs will see this failure and think it's a bug in setuptools. > >> Okay, no point in continuing that rant. Instead, a counter-meme is >> required, to permit easy education of developers. Maybe something >> like, "Debian thinks that users aren't developers, so they strip >> out everything that might be used to develop software. Make sure >> you have a '-devel' package for *everything* on your system, >> because otherwise it's impossible to tell what things will be >> broken when you try to develop software." That has at least some >> chance of allowing things to work, at the cost of having to be >> repeated to every single developer that encounters the problem, and >> for every Python package that might be their point of entry to >> discovering the problem. >> >> Unfortunately, this is a religious issue, which means it is not >> solvable by merely technical means. > > I'm afraid you're right. What really annoyed me the last time debian > vs. eggs was discussed here was that some Debian packagers honestly > believe that they know better than the authors of packages what the > dependencies of those packages are. There is a not-quite-overt cultural issue here: if we automate the production of .deb files using the original authors' specifications, then we remove the possibility of needing a Debian developer to be the "maintainer" of said packages. >> If it were possible to have a mapping from PyPI projects to Debian >> packages, it would at least be possible in theory for setuptools to >> notify the user of the missing Debian package. However, Debian >> policy conflates various meanings of "package" in a way that is >> utterly incompatible with such a mapping, only manual mapping is >> possible. Essentially, there would have to be some kind of >> *manually maintained* global mapping of PyPI project names to >> Debian package names. If somebody in the Debian community wants to >> create and maintain the thing, then in theory at least, setuptools >> could use it to tell the user to install the Debian packages, or >> invoke the corresponding package installation tools. > > Does debian really split some projects into multiple debian packages > (excluding -devel variants)? I know they do this for some non-python > stuff, but haven't noticed this for python software yet. Not that I'm > likely to notice, the only Debian machine I manage at the moment > isn't running much python software. - From a packager's point of view, it might be sensisble, especially for things like the conditional dependencies called out in setuptools' "features": GUI support might be optional, for instance. > Given that at least some Debian developers think setuptools is > superfluous I wouldn't hold my breath waiting for a volunteer that > maintains a mapping from PyPI to debian package names. Maybe the pool is not Debian-developers-who-use-PyPI, but PyPI-developers-who-use-Debian. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE10Hz+gerLs4ltQ4RAr0fAJ0fiMvkA2KXefoiJlOwHiI5ki9uQwCgzjsh gDoKL8kxvJTd1hGJqHT09G4= =Urpg -----END PGP SIGNATURE----- _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
