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. 

Logged In: YES 
user_id=46780

v0.2: Implement self.root optimization from how it was done 
before. 
v0.3: self.distribution.data_files can be None. 

Logged In: YES 
user_id=46780

v0.4: fix dists using extra_path; hardcode site-packages 
instead 

duplicate of issue755286

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>
> _______________________________________