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 :)

So let's have a look after four years.

As far as I know we never got the proposed guidelines so that we could vote on them. So the only thing that we should try to mess with is probably referencing

Loads of packages still reference manpages in a way that would break if those manpages don't end in .gz. Over 600. Only 28 packages refer to info pages in this way.

Similarly, something like 400 packages mark manpages as documentation.

I see 53 packages with a %verify marker on %ghost files.

So, yeah, that's a lot of packages. But without some hard guideline against these things, the only thing that we would really start a process to fix would be the manpages specifying ".gz" directly. Writing guidelines for these wouldn't be hard, really, but I guess I'm having trouble seeing the harm in most of these. Just that man and info page compression might change. Can someone point to any actual harm from redundant %doc marking or %verify on ghosted files? Certainly our examples should never use those things, but as far as I can tell, none do.

Finally, I would suggest that some of these things get into rpmlint. I know we have some rpmlint-savvy people who could perhaps comment on whether upstream rpmlint might be interested in checks for these things. Perhaps if we had those checks we would would at least see the number of problematic packages limited to what we have now.

The flatpak case is fixed now, by the way - it correctly passes prefix to %__brp_compress now so that the same .gz compression is applied to man pages there.

Regardless, I think * or .* is still more correct that hardcoding .gz, if we ever want to change the compression.