Bugzilla Bug 205147

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 an attachment (id=140597) [details]
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 an attachment (id=176484) [details]
compress patch

if COMPRESS is set in the env as an abs path, then man will use that to do the
compression.

Created an attachment (id=176485) [details]
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.