On 07:59 pm, fdrake at acm.org wrote: >I'm actually in favor of removing the bdist_* from the standard >library, and allowing 3rd-party tools to implement whatever they need >for the distros. But I don't think what you're presenting there >supports it. I do think that it's relevant that the respective operating system packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not very useful to have a bdist_deb that nobody actually builds debs with. This has been a problem for me, personally, since debian has made various ad-hoc change to Twisted or Twisted-based packages to break our plugin system, since the distutils metadata has been insufficient for their purposes. If the deb-generating stuff were in a separate project with a faster release cycle that were easier to contribute packages to, perhaps debian packagers could be convinced to contribute their build- hacks there (and bdist_deb could invoke debhelper, or vice-versa). It would be great if someone could volunteer to maintain this stuff independently, put it in a Launchpad project or something. IMHO it would be better for the community at large if this were spun as "increasing the release speed" of the bdist_* family, rather than "removing", which seems to me like it would generate another teacup- tempest on the blogowebs. Of course I'm not volunteering, but I will be best friends forever with whoever does this PR/maintenance :). Given that py2exe and py2app (which includes "bdist_mpkg") are both based on distutils, it seems like we're on the way to independent maintenance anyway. Perhaps bdist_wininst/_msi could be donated to the py2exe project if they would be willing to maintain it, and the new project for _deb and _rpm could be called "py2packman" or something.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4