sys-apps/man-1.6f has broken COMPRESS option in its man.conf It is also missing app-arch/lzma dependency. Another missing option is .lzma decompression. Correct COMPRESS line would be: COMPRESS /usr/bin/lzma e -si -so (see caveat below) Decompression should be: .lzma /usr/bin/lzma d -so Caveat: Fixing COMPRESS line uncovers a bug in man - any space in COMPRESS command flags it as unsafe. (I worked it around using a script)
Only happens if you have app-arch/lzma installed at the time of the installation.
app-arch/lzma is not supported. use app-arch/lzma-utils if you want proper decompression support.
If it's not supported (and breaks man), it should be masked. Please mask app-arch/lzma then. Also, please fix .lzma decompression line.
(In reply to comment #2) > app-arch/lzma is not supported. use app-arch/lzma-utils if you want proper > decompression support. vapier, you missed the point. sys-apps/man *default* to (misconfigure) lzma when you compile it w/ lzma installed. automagic, broken.
what i meant is that it isnt supported by man the lzma line is not broken if you use lzma-utils, thus there is nothing to fix no, i didnt miss the point ... man will add compression lines if binaries exist on your system ... the only thing that changes is the config line. whether i always force the .lzma line to "-d -c" or let the man configure script check for it the end result is the same: do not use lzma compression with man and the lzma package
vapier, this is plain broken automagic junk. You should get exact same package no matter what you have installed on your system, unless there's a USE flag to alter the default configuration. To reproduce and break your man out of the box: 1/ emerge app-arch/lzma 2/ emerge sys-apps/man 3/ read /etc/man.conf If you are refusing to fix this in sys-apps/man, then make it block app-arch/lzma.
(In reply to comment #5) > the lzma line is not broken if you use lzma-utils, thus there is nothing to fix Plus it's broken w/ lzma-utils as well 1/ emerge app-arch/lzma-utils 2/ emerge/upgrade sys-apps/man - it now defaults to lzma compression 3/ unmerge/depclean or whatnot app-arch/lzma-utils because you don't need it any more 4/ you have broken your man without any way whatsoever to detect why it happened Unless man always defaults to stuff that's guaranteed to exist on every system our there (.gz/.bz2) it can't be automagic.
i was thinking of the trailing suffix definitions for decompression bindings, not that COMPRESS is used for cat/cache maintenance ive added a blocker against app-arch/lzma
Well thanks, however as noted in Comment #7, lzma is not a sane preferred default for this... Oneliner patch attached, making the blocker unneeded as well.
Created attachment 140597 [details, diff] man-1.6-bzip2-default-compress.patch
that argument is inaccurate. it applies to every compression in man, not just lzma-utils.
(In reply to comment #11) > that argument is inaccurate. it applies to every compression in man, not just > lzma-utils. Well, unless you want to add a bunch of use flags for every compression supported minus gz/bz2 instead of a trivial oneliner (that defaults to bzip2 which is *guaranteed* to exist on every Gentoo system and so man will always default to it), I don't see what you are after here. The current blocker doesn't fix the problem mentioned in Comment #7.
*** Bug 205903 has been marked as a duplicate of this bug. ***
I would concur that, if a compression method is employable by man via a package that isn't provided by `emerge system` - and we _want_ to support said method - then it perhaps ought to be subject to a USE flag to avoid the problem described in comment 7. That man is deciding during the build process which compression method it will use as a default is problematic. For man to decide to use lzma of its own accord thus makes lzma-utils a functional dependency beyond the knowledge of the package manager. On the other hand, the user can edit /etc/man.conf at any time (also beyond the knowledge of the package manager) but I think it's reasonable to assume that most users would not bother editing man.conf. I sure as heck don't. There can be no question that lzma is good at what it does. However, the main argument against using it is that the overheads during compression are significantly greater than bzip2, both in terms of CPU and memory useage. On the other hand, the memory requirements of lzma during decompression are similar to bzip2 and it's apparently faster at decompression. All in all, I think bzip2 should be a static default and I support the patch attached to this bug. Let's look at this in practical terms. If the user wants to switch to lzma (or any other compression method) then they can still do so, and they will know what they're doing. After all, they _chose_ to edit man.conf and they should be _aware_ of the requirements entailed by their changes. On the other hand, users who couldn't care less which compression method that man uses but want to employ lzma for other reasons (including myself) might well be surprised to encounter the problem that's the topic of bug 205903. We can't expect all users to be so judicious that they are going to scrutinise the new man.conf so closely as to notice 7zma sneaking in as a default compression method. I consider myself to be an advanced user and could easily envisage this catching me off guard. In fact, it's a bit of a pain - I actively don't want lzma as a compression method in man but want to continue to have lzma-utils installed on my system. Thus, I will need to remember to ignore that particular change upon each occasion that man is emerged in the future. So, please, let's just make bzip2 a default and let users who want to customise man.conf do so of their own accord.
Well, reopen. With coreutils not DEPENDing (but not RDEPENDing) on lzma-utils, everyone will be affected by this. Please make something that is *guaranteed* to exist on every system out there a default compressions, lzma-utils is not one of those.
In addition to app-arch/lzma, it also breaks with the lzma implementation in app-arch/p7zip (which provides /usr/bin/lzma). I am not an expert, just a user, but I think perhaps the same treatment for app-arch/lzma should apply to app-arch/p7zip if the lzma COMPRESS support is to be used.
I've just been hit with this too. IMO, USE=lzma makes the most sense.
*** Bug 245036 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > Well, reopen. With coreutils not DEPENDing (but not RDEPENDing) on lzma-utils, > everyone will be affected by this. Please make something that is *guaranteed* > to exist on every system out there a default compressions, lzma-utils is not > one of those. > @base-system: The ability to view man pages is broken on binary hosts unless we can get something to rdepend on lzma-utils. In this case, I build in a chroot and that has lzma-utils installed because other packages DEPEND on it then man generates a man.conf that uses /usr/bin/lzma. lzma-utils does not get installed on the install host using emerge -K. Please consider adding lzma-utils to RDEPEND (the most proper, IMO) or maybe it is time to add lzma-utils to the system set?
Created attachment 176484 [details, diff] compress patch if COMPRESS is set in the env as an abs path, then man will use that to do the compression.
Created attachment 176485 [details, diff] man-1.6f-r2.ebuild.diff If USE=lzma is set then COMPRESS is set to /usr/bin/lzma. Initial testing seems to work as desired.
Cardoe reviewed my attached patches and approved. The new USE flag 'lzma' is now on 1.6f-r3. Please contact me if there are any issues. Also sent patch to email on the HOMEPAGE.
