Attached patch adds --record-rpm option to distutils,
that allows generating of rpm-like filelist, that
contains also directories. Currently most rpm vendors
are using some external commands to get dir list or
have hard coded it in spec file.

Logged In: YES 
user_id=192186

Updated version fixes problems with self defined get_outputs
methods.

Logged In: YES 
user_id=192186

One more update:
- fix generating of dirs in chrooted installs for install_data
- don't include directory for install_scripts

Logged In: YES 
user_id=192186

Version 4 improves handling of mutliple levels of install
directories.

Logged In: YES 
user_id=192186

Sorry for posting buch of patches here, but I test it with
more and more modules and I find more and more problems :-)

Logged In: YES 
user_id=192186

Version 6 now works as expected for all python packages
using distutils in SuSE distro.

Logged In: YES 
user_id=21627

I like the feature, but not the implementation:

- The option should not be called "record-rpm", as it does
not record
  RPM files, but directories.

- RPM-specific code should be completely restricted to the
bdist_rpm 
  command. For the case of directories, you should create a
mechanism
  to collect all directories, and then traverse this list to
create the 
  proper %dir directives in the spec file.

- I'm not sure that overloading get_outputs is a good idea.
Instead,
  introducing get_output_dirs might be better.

Logged In: YES 
user_id=192186

I agree, that the implementation is not perfect. It's mostly
quick hack, that needed to be written to avoid
postprocessing of generated file lists. I'm open to rewrite
it when somebody gives me better idea for implementation,
but probably I won't have time for this in next month.

Why I called it record-rpm - it does same as record, but
adds directories needed for rpm.

Limiting to bdist_rpm is IMHO not good idea, as in this case
it is not usable for distribution vendors (bdist_rpm is not
suitable for this case, at least as I see situation in SUSE).

I choose overloading get_outputs just to avoid code
duplication in many cases.

Logged In: YES 
user_id=21627

We are not much interested in quick hacks. Are you willing
to revise your implementation to make it well-designed? If
not, I'll reject it (and hope that somebody else will submit
a well-designed implementation of that feature in the future).

Logged In: YES 
user_id=192186

It would be probably best, if somebody with more knowledge,
how distutils work, would help with design.

Logged In: YES 
user_id=21627

I can pose a few principles: put RPM-specific code just into
bdist_rpm, and enhance other commands to provide generic
functionality which might be usable only to RPM at the
moment, but could be useful more generally in the future.

Also, make sure all commands continue to work if no RPMs are
built (e.g. the standard "install" command should continue
to work).

I think you code is quite close algorithmically, it just
needs to be re-arranged  a bit.

Logged In: YES 
user_id=192186

I still do not see how to put that into bdist_rpm and keep
it usable:

- bdist_rpm creates tarbal and then calls rpm which builds
it and the installation itself is done by install

- when building package for distribution (SUSE) bdist_rpm is
not used at all

Logged In: YES 
user_id=21627

Then I don't understand how your patch works: Does it not
generate %dir lines for the .spec file? And isn't the spec
file generated by the bdist_rpm command?

Logged In: YES 
user_id=192186

It does extend --record with directory entries. This
resulting file is then used by rpm:

%install
python setup.py install --root=$RPM_BUILD_ROOT
--record-rpm=INSTALLED_FILES

%files -f INSTALLED_FILES
%defattr(-,root,root)

Logged In: YES 
user_id=21627

I see. Wouldn't it better if the bdist_rpm command would
generate a .spec file that completely contains all
directives? Then, this could be enhanced to make use of more
features of RPMs, such as %doc, %docdir, %verify, etc.

It would also allow to keep RPM specifics out of the install
command.

Logged In: YES 
user_id=192186

As I said bdist_rpm is not suitable for building packages in
distribution - all packages are built same way using spec
file and sources (+patches). And this building packages for
distribution (I work for SUSE) is main goal why I did this.

Logged In: YES 
user_id=21627

It is unfortunate that bdist_rpm is not useful to generate
RPMs for distribution, because this is the primary purpose
of that command: generating RPMs. So if the command does not
meet your needs, we should change it to make it meet your
needs. E.g. would it help if bdist_rpm would generate the
.spec file for you?

Logged In: YES 
user_id=192186

It's pripary purpose is IMHO to allow building of rpms when
you distribute some python stuff. It is good for this case.

The problem for distributions, is that all packages need to
be handled same way (in case they use some automatically
building system), so you can not differ whether it is
packaged some python stuff or kernel. So separate spec file
and sources is the only solution. Generating spec file
doesn't help much as it can get changed every version and
vendor has own additional information in spec file, which
would require hand merging.

Another idea I just got is to generate just file list using
separate bdist_rpm and use it separately, but I'm not sure
whether it is doable - information about file list is not
probably available there, is it?

It would be used like:

python setup.py install --root=$RPM_BUILD_ROOT
python setup.py bdist_rpm --filelist=INSTALLED_FILES

Logged In: YES 
user_id=21627

This might work. bdist_rpm would have to invoke the install
command, but only to compute the file list, instead of
actually performing copying.

Logged In: YES 
user_id=21627

Alternatively, adding --record-dirs to the install command
would be acceptable as well, so you could post-process the
directory list, e.g. with awk.

Logged In: YES 
user_id=192186

After long delay I finally found time to look at this.

I decided to go other way that doesn't need soo much
modifications. Instead of adding directories during copying
and messing all the code, it now just postproceses filelist
and generates directory list out of that. This leads to much
smaller patch and need to modify just one file. I'd like to
hear comments from you.

I currently tested just few packages and I'll give it more
testing in next days.

Patch is against 2.4c1.

Logged In: YES 
user_id=192186

Here is a bit updated version, only thing that has changed
is list of directories not beeing included in output.

Duplicate of issue1035576

This appears to be a feature request. That would normally now mean this issue is applicable to 3.2 only. Or is the rule different for disutils?

Should #755286 and #1035576 both remain open?

Tarek, does distutils2 work supercede these?

Nijel, could at least some of the earlier versions of the patch be removed (people normally do this when submitting better versions)?

See Tarek's message on #1035576.