Chris Withers writes: > aptitude also won't help when: > - your customer is deploying onto managed machines running RHEL
True. > - debian has an outdated and/or broken version of your package. True, but just as for the package system you are advocating, it's quite easy to set up your apt to use third-party repositories of Debian-style packages. The question is whether those repositories exist. Introducing yet another, domain-specific package manager will make it less likely that they do, and it will cause more work for downstream distributors like Debian and RH. > The latter is a standard problem with Zope/Apache/Postgres in > debian and causes much gnashing of teeth by people trying to > support them. The Debian guys love buggering around with other > people's packaging, not caring that it makes supporting stuff so > much harder. Well, I can't speak for the Debian Zope/Apache/Postgres maintainers, but I assure you the Emacs maintainers do care. But their hands are full trying to implement what you keep proposing as a solution, viz., a "batteries-included distribution built on top of a package system". If you don't like Debian, fine, as an upstream vendor, I don't either. But an awful lot of my users *do* like[1] Debian (or Ubuntu or another Debian-derived distro). I see no alternative to cooperating with them (though I sometimes complain loudly throughout the process<wink>). If you want to see where the kind of thing you propose can lead, take a look at the Debian Emacs Policy document, which is designed to deal with one fork that takes the batteries-included approach, and another that has gone a long way in the direction of unbundling packages. Note that while Python doesn't have a political fork of the kind that Emacs does, it *does* have multiple blessed technical forks, and your suggestion involves the creation of yet more forks (ie, the distributions with bundled packages, versus those without). Whether the technical differences among Python implementations and packaging strategies will lead to the kind of issues that form the background of the Debian Emacs Policy, I don't know. But you don't know either. > A cross-plaftorm, platform agnostic, python-centric package > management system is what's needed. That's what you (think you[2]) need, but that statement rudely ignores the stated requirements of many other users. What you are doing here is divisive, not unifying. > Setuptools comes close, but I wonder if it's impossible to get it > to do the last bits of what's needed (uninstall being the big one, > and knowing what version of what package you have installed!) Why wonder, when you can try an implementation and report the results? I guess you mean you hope somebody else will do the work (not only of development, but of maintaining the package repository). Well, "somebody else" has *already* done "the work", but unfortunately<wink> they defined "the work" in their own way. The result is the batteries-included stdlib. Footnotes: [1] For values of "like" including but not limited to "see no superior alternative to". [2] If "your users" include Debian and RHEL users, you may find that they are not so happy with yet more PMS. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
