Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 164969 - app-editors/emacs-21.4-r5 does not install manpages properly
Summary: app-editors/emacs-21.4-r5 does not install manpages properly
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Emacs project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-02 11:21 UTC by Ulrich Müller
Modified: 2007-02-27 18:39 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Müller gentoo-dev 2007-02-02 11:21:06 UTC
emacs-21.4-r5 installs its manpage in /usr/share/man/man1/emacs.emacs-21.1.gz, but does not provide a symlink to emacs.1.gz. The same applies to the manpages for ctags, etags, and gfdl.
Comment 1 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-02 14:41:04 UTC
Fixed in 21.4-r6, emacs-cvs 22.0.93-r2 and 22.0.9999-r2.  Thanks for the notice.
Comment 2 Ulrich Müller gentoo-dev 2007-02-02 16:11:07 UTC
(In reply to comment #1)
> Fixed in 21.4-r6, emacs-cvs 22.0.93-r2 and 22.0.9999-r2.

That fix was a little too quick (since it doesn't work). Reopening.

I believe you have to do something like the following, in update_alternatives (untested code):

    local suffix=$(ecompress --suffix)
    for i in emacs etags ctags gfdl; do
        alternatives_auto_makesym "/usr/share/man/man1/${i}.1${suffix}" \
            "/usr/share/man/man1/${i}.emacs-*.1${suffix}"
    done

This is probably still too simple-minded, since it doesn't handle the case that the compressor program (specified by PORTAGE_COMPRESS) has been changed between installation of different emacs versions.
Comment 3 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-02 20:16:31 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Fixed in 21.4-r6, emacs-cvs 22.0.93-r2 and 22.0.9999-r2.
> That fix was a little too quick (since it doesn't work). Reopening.

 Right (second time this weeks that happens to me, shouldn't fix bugs short before leaving).
 
> I believe you have to do something like the following, in update_alternatives
> (untested code):

 I can't do it.  ecompress is new in Portage 2.1.2, so I break stable users.  I hardcode .gz suffix for the moment.
 
> This is probably still too simple-minded, since it doesn't handle the case that
> the compressor program (specified by PORTAGE_COMPRESS) has been changed between
> installation of different emacs versions.

 I think of a different solution, maybe extracting the suffix from the installed file.  Let me think about it.
Comment 4 Ulrich Müller gentoo-dev 2007-02-02 23:38:46 UTC
(In reply to comment #3)
>  I can't do it.  ecompress is new in Portage 2.1.2, so I break stable users.

Hm. You could do:
    local suffix=".gz"
    type ecompress &>/dev/null && suffix=$(ecompress --suffix)

but of course it would still not solve the next problem:

> > This is probably still too simple-minded, since it doesn't handle the case that
> > the compressor program (specified by PORTAGE_COMPRESS) has been changed between
> > installation of different emacs versions.

>  I think of a different solution, maybe extracting the suffix from the
> installed file.  Let me think about it.

I seems that alternatives.eclass does not work well together with the new ecompress. There are several other ebuilds in the tree that have the same problem (e.g., dev-lang/python hardcodes the ".gz" suffix for the manpage).
Comment 5 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-03 11:42:27 UTC
local suffix=`ls /usr/share/man/man1/emacs.emacs-* |sed s/".*\."//g|tail -n 1`

extracts the last suffix and uses it afterwards.  I spoke up in gentoo-dev mailinglist and reported your concerns regarding the alternatives.eclass.  Thanks for the help.
Comment 6 Martin von Gagern 2007-02-05 17:57:21 UTC
I just reported bug 165466. There are some interesting connections to this here.

I got a symlink with a wrong suffix:
# ls -l /usr/share/man/man1/ | grep emacs.emacs
lrwxrwxrwx 1 root root     19 Feb  5 16:35 emacs.1.gz -> emacs.emacs-21.1.gz
-rw-r--r-- 1 root root   5548 Feb  5 16:34 emacs.emacs-21.1.bz2

The symlink was definitely from the same install, it's in the ebuild log as well: 
 * Linking /usr/share/man/man1/emacs.emacs-21.1.gz
   to /usr/share/man/man1/emacs.1.gz (relative)

Could it be that an old version was still available during postinst, which contained a gz file, and was only removed after the symlink was in place?

I noticed a minor issue in the suffix detection code: suffix=".`ls ...`" will always start with a dot. So the immediately following check should take that dot into account. And of course it should compare a variable. So instead of
``[ suffix = 1 ]'' it should be ``[ "$suffix" = .1 ]'' or something similar.
I haven't tried any of this, but I'm pretty sure it won't work as intended the way it is right now.

Another observation I made in bug 165466 might be useful to the extension issue. It seems like emacs installed its manpages in an uncompressed form into
/usr/share/emacs/$SLOT/etc. If you tweaked the alternative symlinks to link to
$(ls /usr/share/emacs/*/etc/emacs.1 | tail -n1) you would always get the latest version in an uncompressed form - as long as they get installed like this.

Which reminds me of another point to keep in mind: who is going to clean up those alternative symlinks? You could emerge one package with gz man page, then update and get a bz2 man page, and from then on update-alternatives would only ever look at the bz2 files. The gz file would stay around to rot. The same problem arises if you decide to link to the uncompressed man pages mentioned above. Maybe update-alternatives should clean out old symlinks even if the differ in extension. How about this:

  for j in emacs emacsclient etags ctags
  do
+   for s in "" ".gz" ".bz2"
+   do
+     if [[ -L "/usr/share/man/man1/$j.1$s" ]]; then
+       einfo "Removing old symlink /usr/share/man/man1/$j.1$s"
+       rm "/usr/share/man/man1/$j.1$s"
+     fi
+   done
    alternatives_auto_makesym "/usr/share/man/man1/$j.1${suffix}"
                              "/usr/share/man/man1/$j.emacs-*"
  done

Maybe this should be in alternatives.eclass as well. Generally perhaps all this alternative man page handling should go into that eclass.
Comment 7 Ulrich Müller gentoo-dev 2007-02-05 18:54:57 UTC
(In reply to comment #6)
> I noticed a minor issue in the suffix detection code: suffix=".`ls ...`" will
> always start with a dot. So the immediately following check should take that
> dot into account. And of course it should compare a variable. So instead of
> ``[ suffix = 1 ]'' it should be ``[ "$suffix" = .1 ]'' or something similar.
> I haven't tried any of this, but I'm pretty sure it won't work as intended the
> way it is right now.

You are right, that wouldn't work.
However, the extra test for "no compression" is not necessary at all, the following should handle all possible cases:

local suffix=$(echo /usr/share/man/man1/emacs.emacs-*.1*|sed 's/.*\.1//')

Wildcard expansion will already sort the entries, and there is even no need for the extra "ls" and "tail" commands.

As I have said before (in comment #4), it looks like alternatives.eclass and ecompress don't really go together.
Comment 8 Ulrich Müller gentoo-dev 2007-02-27 18:33:06 UTC
There is still some (trivial) problem: emacs-21.4* passes
"/usr/share/man/man1/$j.1${suffix}" (which is right)
as first argument to alternatives_auto_makesym, whereas emacs-cvs-22.0.* uses
"/usr/share/man/man1/$j.1.${suffix}" (which is wrong, note the additional dot).

Since ${suffix} already contains a dot (it is ".bz2" or ".gz"), this will result in symlinks named, e.g., "emacs.1..bz2".

Reopening.
Comment 9 Christian Faulhammer (RETIRED) gentoo-dev 2007-02-27 18:39:36 UTC
There is no dot, never was, you are sleepy now, you will confess that there never has been a dot when I clap my hands.

Resolved. <clap>