well, there is a problem that people will put it again =(

I guess the real question is whether these hurt anything. Not that I'm personally above doing cleanups, but I prefer to have them backed up by packaging guidelines or else it does cross over onto the wrong side of pointless churn. And the only thing that appears to be potentially against a guideline would be the explicit compression suffix, though a quick read of the text (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages) shows that the language could use a cleanup to indicate that there's actually a prohibition there (by adding SHOULD or SHOULD NOT appropriately).

If I get a few minutes I'll add checks to the fedora-misc-package-utilities repo, which is where things like this have been collecting.

I guess the real question is whether these hurt anything. Not that I'm personally above doing cleanups, but I prefer to have them backed up by packaging guidelines or else it does cross over onto the wrong side of pointless churn. And the only thing that appears to be potentially against a guideline would be the explicit compression suffix, though a quick read of the text (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages) shows that the language could use a cleanup to indicate that there's actually a prohibition there (by adding SHOULD or SHOULD NOT appropriately).

If I get a few minutes I'll add checks to the fedora-misc-package-utilities repo, which is where things like this have been collecting.

Somehow that reposted when I restarted my browser. Weird.

find -maxdepth 2 -name '*.spec' -exec sed -i '/%{_mandir}/ s/\.gz/.*/g' "{}" \;

Instead of .* please use * so that the glob works when there is no man page compression (this is currently the case for flatpaks).

@kalev yeah, I agree.

FTR, I'm huge +1 to cleanups which were proposed in this ticket. I think exact scripts need a bit more love, but…

Also I agree with @tibbs that we need to have those things baked by guidelines.

We talked about this issue this week:

https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-07-11/fpc.2019-07-11-16.00.txt

• #902 Cleanup & enhance spec files (geppetto, 16:33:51)
• Propose guideline changes we can vote on, if those pass then it's
  fine to do scripted cleanups (geppetto, 16:44:11)

We talked about this issue this week:

https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-26/fpc.2019-09-26-16.00.html

• We should document that man pages are automatically marked as %doc and the packagers don't need to mark them as such

I submitted #930 to tighten up the language in the manpage section a bit and adds a note about %doc not being needed.

A couple of questions (mostly to @kalev):

• Why doesn't flatpack compress the manpages?

• What happens to flatpacks if someone installs an already-compressed manpage? Does it still work or do we need to consider changing SHOULD be installed uncompressed" to "MUST be installed uncompressed"?

I'm pretty sure for regular packages, RPM will leave already-compressed manpages alone, but I don't actually know.

For "fun", it would be interesting if someone tried changing to some newer compression method for manpages just to see if it actually saves anything. And to see what packages break.

I don't know why man pages don't get compressed when building for flatpak. It's possibly just a bug somewhere; I haven't looked into it. I suspect the bug is that the rpm brp script that compresses man pages only does so for /usr/share/man and not for /app/share/man.

I can't think of anything that would break when installing already-compressed man pages.

So %__brp_compress (i.e. /usr/lib/rpm/brp-compress) will be called to compress manpages. The script accepts a prefix, but currently none gets passed. I believe that should be fixable, but I do not know how flatpack building works. If it's just redefining %_prefix then I think it should always be safe to simply pass %_prefix to brp-compress. This is probably not the best place to talk about that, though. And I'm not the best person to file tickets because I don't know how flatpack builds actually work, but maybe that would give you enough to file a reasonable ticket.

That does also raise the question of whether RPM will automatically mark things in /app/share/man as %doc, and whether that matters at all. I believe that list is controlled by %__docdir_path, which uses %_datadir, which is defined in terms of %_prefix. So if %_prefix is being redefined then I would wager that this works already.

Ah, thanks! I'll see if I can get the compression stuff fixed at some point.

%_prefix (along with a few other things) is redefined in flatpak-rpm-macros. Hopefully %doc already works correctly, yes :)