When a man page is in data_files, the rpm installer
compresses it with gzip (done by the brp-compress
script). I attached a little hack for
install_data command to add a ".gz" to such man pages.
Then it works for me.

Of course, the proper fix would be to detect if
brp-compress is run and what files were compressed by
the script. But I am not an rpm guru, so its up to you
how you want to fix it.

I am using a Debian Linux unstable boxen with Python
2.2.2-2, and rpm 4.0.4-11

Logged In: YES 
user_id=9205

Finally I got around to investigate this a little more. What
essentially happens is this:
1) bdist_rpm generates a .spec file with the following
install command:
python setup.py install --root=$RPM_BUILD_ROOT
--record=INSTALLED_FILES
.. and the following files section
%files -f INSTALLED_FILES

2) if the setup.py installed any man pages, then after
%install and before %files rpm runs brp-compress (usually
found in /usr/lib/rpm/brp-compress) which compresses all man
pages with gzip.

3) Now the man pages have a '.gz' suffix, but the
INSTALLED_FILES file lists them still without the suffix.
The %files section of the rpm .spec file will fail.

The solution in my case was to use a custom rpm-install
script configured with setup.cfg:
[bdist_rpm]
install_script = install-rpm.sh
The install-rpm.sh file is attached.

The solution is not very generic - brp-compress compresses a
lot more files than the install-rpm.sh detects. But at least
there should be a documentation somewhere about the
brp-compress pitfall.

Duplicate of issue1169193

Attaching a reworked patch of the patch attached in
http://bugs.python.org/issue1169193

This worked for me on f-11, with python 2.6

I'd rather see sed called from within Distutils. But I am not sure how
to handle it after install has been called.

Do you know if sed is *always* present on a fresh Fedora ?

(I am nosying Toshio as well)

sed is one of the programs we assume is always present when we build
packages in Fedora which is probably also what is wanted here.  (A
default install of Fedora will include sed but someone might be able to
create a minimal install that did not include it.) Note that within
Fedora we usually use a wildcard with man pages.  For example::

  %{_mandir}/man1/foo.1*

I'd suggest doing this rather than hardcoding ".gz".  Automatic
compression of manpages could be disabled on other distros, set to
bzip2, compress, or xz instead.  Wildcarding the suffix will catch all
of these cases and be more future-proof.

Hi Toshio,

I'd probably also go for the wildcarding, but you'd still need to
'change' the INSTALLED_FILES file to do so, so you'd still use the same
mechanism.

Agreed.  The substitution is still needed.

Ok, so this patch can go in as is except for changing .gz to * ?

Correct.

Distutils is frozen, since changing even internal details breaks third-party tools, and Distutils2 has removed RPM support, since it’s better handled by OS-specific tools that comply with various policies and have smaller release cycles. Tarek, are you closing this bug?

What do you mean, it's frozen ? Without the patch you're already breaking a third party tool, namely rpm.  What other tool worth caring about that uses bdist_rpm could possibly get broken by fixing an obvious bug ? Why is it so impossible to simply fix a bug for a feature that people are trying to use and are baffled by having it not working ?

Anyone got a reply for msg107898?

Thomas, sorry if my message was short and unclear.  The freeze policy means that distutils does not get new features, only bug fixes.  The goal is to free time so that the developers (especially Tarek) can work on distutils2, the next generation.  When I said that “changing even internal details breaks third-party tools”, I was talking about tools written in Python that use distutils as a library; they rely on implementation details, internal functions and old bugs, which means distutils can’t get the changes we need to significantly improve the state of Python packaging.  That’s why Tarek has started distutils2, where compatibility can be broken to fix design mistakes and add disruptive new features.

Like I said, we’ve removed bdist_rpm in distutils2; it now lives as an external project: https://pypi.python.org/pypi/pypi2rpm/0.3 .  When distutils2 is merged back into the standard library, bdist_rpm2 can have shorter release cycles to comply with policy changes on rpm-based systems.

In this case, the freeze does not apply: This bug should be fixed in distutils.  Can you update your patch to address Toshio’s remarks?  Thanks.