One major weakness of the current usage of INSTALLED_FILES in bdist_rpm leaves directories unlisted thereby causing an uninstall of a package to leave these behind. This patch separates out into another option --record-rpm and function that generates a list friendly for RPM consumption. It currently handles data_dirs and install_lib (everything under site-packages). In addition, languages found under the common LC_MESSAGES sub-directory is also automatically tagged with %lang(de) attribute. Documentation does not need to be handled since RPM already sets this up if the packager uses %doc. I've run a couple of tests with this patch showing good results. Before taking the concept further, I submit it here for your review.
This appears to be a feature request. That would normally now mean applicable to 3.2 only. Or are the rule different for disutils? Should #755286 and #1035576 both remain open? Tarek, does distutils2 work supercede these?
distutils is now frozen in all branches, so not accepting new features but just bug fixes. although distutils2 will not provide bdist_rpm, and I'd suggest the command to live on its own, in a new project (like bdist_deb did in stdeb). The benefit is to have a different release cycle which can follow the rpm world. So yes, all pending feature requests to build_rpm, should be closed.
On 6/26/2010 5:36 PM, Tarek Ziadé wrote: > > Tarek Ziadé<ziade.tarek@gmail.com> added the comment: > > distutils is now frozen in all branches, so not accepting new > features but just bug fixes. > > although distutils2 will not provide bdist_rpm, and I'd suggest the > command to live on its own, in a new project (like bdist_deb did in > stdeb). The benefit is to have a different release cycle which can > follow the rpm world. Seems like a good idea. > So yes, all pending feature requests to build_rpm, should be closed. Done for the duplicate, and 4 others for bdist_rpm (you should see messages and counter if not correct.) There are also bug reports for bdist_rpm. Close these too? 2945 4495 5474 644744 5875 (test failure) How about any of the other feature requests (there are about 36 others open for distutils). Should they be retargeted to disutils2? > ---------- resolution: -> wont fix status: open -> closed type: > -> feature request > > _______________________________________ Python > tracker<report@bugs.python.org> > <http://bugs.python.org/issue1035576> > _______________________________________
History
Date
User
Action
Args
2022-04-11 14:56:07
admin
set
github: 40957
2010-06-27 00:33:28
terry.reedy
set
messages: +
2010-06-26 21:36:03
tarek
set
status: open -> closedtype: enhancementresolution: wont fixmessages: +
