search

traviscross / mtr

Official repository for mtr, a network diagnostic tool
http://www.bitwizard.nl/mtr/
GNU General Public License v2.0
2.68k stars 340 forks source link

man pages not installed compressed, do not replace compressed versions #374

Open idallen opened 4 years ago

idallen commented 4 years ago

Running Ubuntu 20.04.1 LTS I have the stock Ubuntu mtr 0.93 installed. Ubuntu uses compressed man pages. When I git clone, build, and install mtr 0.94, the man pages are installed uncompressed. Now I have both, and Ubuntu always picks the old compressed version first, ignoring the newly installed uncompressed versions:

-rw-r--r-- 1 root root  9544 Oct 28 09:41 /usr/share/man/man8/mtr-packet.8      
-rw-r--r-- 1 root root  3397 Aug 20  2019 /usr/share/man/man8/mtr-packet.8.gz 
-rw-r--r-- 1 root root 12599 Oct 28 09:41 /usr/share/man/man8/mtr.8             
-rw-r--r-- 1 root root  5057 Aug 20  2019 /usr/share/man/man8/mtr.8.gz

(My /usr/local is the same as /usr, so they appear in the same directory on my system.)

The mtr install uses the Ubuntu version of install (GNU coreutils 8.30) that has an ignored -c option;

/usr/bin/install -c -m 644 $files "/usr/local/share/man/man8"

Perhaps that ignored -c was supposed to install using compression? It doesn't.

I was going to offer up a little script that checked if the uncompressed page was newer than the compressed page and call gzip if true, but that only works if the compressed page exists before installing the uncompressed version. If someone who did not have mtr installed yet were to manually install mtr from source, then over-write it by installing the Ubuntu packaged mtr (with the compressed man page), you'd again end up with two versions of the man pages. I hope someone who understands the whole build system has an elegant solution.

rewolff commented 4 years ago

How about compressing the manpage in our source directory and then installing the gz version?

On the other hand.... I understand the annoyance, but you getting rid of the old stock-version is more or less your responsibility. What if we compile to install in /usr/local, and you have another version in /usr/bin that gets found first because it is earlier in you $PATH ?

idallen commented 4 years ago

If I have separate /usr and /usr/local, then both the man pages and the binaries are separate (I can have both new and old installed), and I get to choose which one I get first based on PATH and MANPATH (which, of course, should agree on which is first). Having one man page compressed and the other not compressed is ugly, but it doesn't cause any problems or any unexpected behaviour.

For systems installing directly into /usr, not /usr/local, a user does not expect that installing a new mtr binary to replace the old one does not also give the user a new man page to replace the old one, because the installed man page is in the wrong (uncompressed) format. That's not expected; that's not good. If the new binary replaces the old binary, the new man page must replace the old man page.

Ignoring the /usr//usr/local issue, the build system should install man pages in the format (compressed or not) native to the system at hand. I think something even runs around the man page directories and complains about files in the wrong format.

I don't know if the build system can know the expected installed format of man pages easily. One might resort to kludges such as checking if /usr/share/man/man1/date.1.gz or /usr/share/man/man1/ls.1.gz exist, and if either one does, assuming that all man pages should be installed compressed, otherwise install uncompressed. Having both compressed and uncompressed is trouble.

rewolff commented 4 years ago

The "kludge" should not work. It is some modern Ubuntu-weirdness to install manpages in /usr/share.... Classical Unix has them in /usr/man.... I don't know how/if mtr makefile determines where to install manpages, but how about: listing that directory (even if now it is just a constant /usr/share/man) and checking for .gz files? Then lets hope that not some other app accidentally installed a single zipped manpage where the system doesn't support that. list all files in man1, list all gz files in man1 and when the ratio of gz is above 0.2, go along with that ?

idallen commented 4 years ago

Yes, /usr/man is traditional (I've been on Unix/Linux since 1976) and I personally symlink /usr/man to share/man so that the traditional path still works for my fingers.

Your idea to check the ratio of .gz files is valid, but I was hoping that the mtr build system had a simple flag for "use compressed man pages". Perhaps not. I found this:

https://github.com/musescore/MuseScore/commit/79ea6132da963e73032af1c49427c22c435541fe

which says "note: compressing man pages is normal on Linux but not OpenBSD" and has code to check that. Perhaps mtr could steal some of that logic?