Bugzilla Bug 66765

Firstly, gnuplot-mode installs an info file without the proper INFO-DIR entries
and it's just a copy of the old gnuplot-3.7 info file anyway and shouldn't need
to be installed at all.

Secondly, the gnuplot-mode package is already incorporated within the
gnuplot-4.0 distribution (don't know about 3.8) but currently doesn't get
installed unless the xemacs USE flag is set. However, this flag forces
installation of xemacs and that is unnecessary and unacceptable for
emacs/emacs-cvs users.

The gnuplot configure script determines which emacs is installed and installs
the site-lisp files accordingly. The script appears to check for emacs before
xemacs so if both are installed I *think* it will only put it's site-lisp files
in the /usr/share/emacs/site-lisp directory for emacs (and not xemacs).

I don't think the resolution of bug #53604 is a good one since a)
emacs/emacs-cvs runs in X too! b) gnuplot could be used in emacs non-X/batch
mode for some purposes and c) it forces emacs/emacs-cvs users to install the
redundant and slightly faulty gnuplot-mode package.

I've made a new ebuild in accordance with what appears to be standard gentoo
emacs practise (using the portage elisp mechanism) and it works well for me
(emacs-cvs installed, USE=emacs,-xemacs). For someone who has only USE=xemacs
and only xemacs installed it should behave properly just as before, for someone
who has both it will probably only configure and install for emacs (see above)
and for someone who has neither it'll work as before. I think it should block
gnuplot-mode and maybe gnuplot-mode could be removed in future (immediately
perhaps if gnuplot-3.8 also has the emacs stuff built in).

Created an attachment (id=41364) [details]
gnuplot-4.0-r1 ebuild patch to improve gnuplot's emacs site-lisp files install

Created an attachment (id=41368) [details]
Added pkg_postrm()

elisp-site-regen needed in pkg_postrm() a la bug #66135

"( use xemacs | use emacs )" should be "( use xemacs || use emacs )", shoudn't
it?
Also, what happens if a user has both xemacs and emacs USE flags set?
(It should install and compile gnuplot-mode.el for both.) 

Anyhow, I'll look into this bug.

Created an attachment (id=41374) [details]
gnuplot-4.0-r1 ebuild patch to improve gnuplot's emacs site-lisp files install

Yes - || not | and a missing fi fixed.

If both flags are set, then both xemacs and emacs will be present when gnuplot
configures. AFAICT the configure script will pick up the presence of emacs but
not both emacs and xemacs and will configure the site-lisp stuff accordingly.
It's quite a complex procedure it goes through and without installing both
xemacs and emacs myself I can't be 100% sure but it doesn't actually matter
because so long as it doesn't detect xemacs and NOT emacs - *very* unlikely I
think - the only thing that can go wrong is xemacs not having gnuplot-mode
immediately available. This would happen *anyway*, with the current ebuild, and
if it does occur it should probably be fixed with an addition to the ebuild to
make symlinks or do the copying.

In the exceptional case that xemacs is detected but emacs isn't, and assuming
I'm right about gnuplot installing only for one *macs, then xemacs will get the
site-lisp files and emacs won't, and 50gnuplot-gentoo.el will be installed
without access to the site-lisp files it needs but this is a case which should
require a modification to the current ebuild anyway and is easy to do for
either ebuild.

I would normally be happy to find out exactly what happens myself but I have
just seen the list of extra app-xemacs/ packages that xemacs drags down with it
and the patched ebuild will only cause a (slight) problem and only in the
highly unlikely exceptional case and only to users who load the site-gentoo.el
file in their ~/.emacs.

In summary, the advantages of the patched ebuild overwhelmingly outweigh the
the disadvantages of the current ebuild and what is only a very small
probability of an easily fixed problem. :-)   

Sweet!  Thanks for this!  

I looked at it in detail. So, what's wrong with app-emacs/gnuplot?
The version of gnuplot.el from media-gfx/gnuplot and
app-emacs/gnuplot-mode seems the same, and I'm inclined to add
RDEPEND="emacs? ( app-emacs/gnuplot-mode )" to the ebuild.
I forced XEmacs if USE="xemacs" is set, so if both USE flags should
be handled correctly if I add it.

Gnuplot already has the gnuplot-mode site-lisp files built-in and it seems
likely to me that in future versions they will be kept up to date and in sync
with the rest of the gnuplot package, whereas the separate gnuplot-mode package
files will not (after all; gnuplot-mode already installs an outdated *gnuplot*
info file and it's lucky it doesn't overwrite the valid gnuplot one).

If you fix the separate gnuplot-mode package (remove the info file
installation) and change the gnuplot ebuild as you suggest then that would be
okay for now - for emacs-only/xemacs-only users at least.

Dual emacsen users however, would still get only the emacs site-lisp files, and
they would be installed twice - once by the gnuplot package (and not properly)
and once by the gnuplot-mode package.

The patch I submitted has the advantages that it always uses the built-in stuff
and won't double install anything, but of course it's no better than your
solution at providing xemacs users with access to the site-lisp files in the
dual emacsen case.

I think it should be easy enough to make the gnuplot ebuild work optimally
(with the built-in site-lisp files and site-gentoo.el update) and in all four
cases (one emacsen, both, neither) and I'll submit one in the next day or two,
so I hope you don't rush to close this just yet.

No, dual emacsen users will have elisp for emacs from gnuplot-mode,
and elisp for xemacs from gnuplot. emacs users always get gnuplot.elc
from app-emacs/gnuplot-mode and xemacs users get one for xemacs
from media-gfx/gnuplot (with USE="xemacs"). No duplicate files except
the el files. (elc from emacs and elc from xemacs are different)

I would rather think having app-xemacs/gnuplot-mode is the best,
but I'm afraid it is unlikely xemacs herd will make xemacs package
ebuild unless XEmacs includes the package. (XEmacs package needs
_pkg.el, auto-autoloads.el, and so on)

Making a single ebuild supporting both emacs and xemacs is too
complicated, IMHO. I made one a while ago (dev-tex/preview-latex)
but don't want to create another one. Creating an ebuild for emacs
and another on for xemacs, and then add 
RDEPEND="emacs? ( app-emacs/gnuplot-mode ) 
xemacs? ( app-xemacs/gnuplot-mode)" to media-gfx/gnuplot
is far simpler than that.

But I've tested with both emacs and xemacs (despite my earlier reluctance to do
so) and as I thought it would, the configure script discovered emacs and built
and installed the site-lisp files for it, but did not care that xemacs was also
present and ignored it. xemacs users would only get the gnuplot-mode files if
you somehow masked the presence of the emacs binary during the src_compile().

I wouldn't wish the gnuplot-mode package on anyone - not even xemacs users ;-)

It won't be complicated to fix this since all that is necessary, when emacs and
xemacs are both present is to run make in the lisp directory a second time
(after a make clean) with EMACS=xemacs (cf lisp/README), then install the files
in the xemacs site-lisp directory as normal. If you can just wait a day or
two...

No problem. I'm not pushing you to make an ebuild. 
I do not do much Gentoo work on weekday ;)

btw, I updated gnuplot-4.0-r1.ebuild yesterday, so please
run `emerge sync` and reopen the file. I disabled the
detection of emacs for gnuplot for the moment. 
You thought so probably because you looked at an
old ebuild.

Setting EMACS=xemacs alone gets elisp compiled for 
xemacs and installed into /usr/share/emacs/site-lisp ;(
Fixing xemacs part (autoload, etc...) is greatly appreciated.

Created an attachment (id=42152) [details]
Modified ebuild for gnuplot-4.0-r1 with support for both emacsen.

I've tested all the combinations now and it turned out that the easiest thing
to do was to handle the various possibilities by just separating the emacsen
stuff from the main gnuplot compile/install. The changes are as follows:

1) Made the gnuplot-mode stuff get configured and installed individually,
according to the USE flags. This seems to work well in all cases.

2) Improved the emacs site-lisp install so that it gets installed to it's own
subdirectory like (some of) the other packages and like the xemacs stuff. The
50gnuplot=gentoo.el file creation is better now too.

3) I put a warning in the xemacs gnuplot-mode part in case the emerge of
gnuplot pulls down the xemacs and xemacs-base packages. This is because
xemacs-base must be installed already for the xemacs elisp compile to work. I
tried putting a DEPEND for xemacs-base in the ebuild but it seems to get
overridden by the PDEPEND coming from xemacs.

There doesn't appear to be a good mechanism like the emacs site-gentoo.el for
xemacs so I couldn't do any better than the previous ebuilds for the xemacs
gnuplot-mode autoload - this ebuild works just the same as the current one in
that respect. As you said, the xemacs herd seem to prefer to control everything
as an XEmacs package so unless/until they supply a mechanism then maybe some
einfo instructions in the ebuild would help?

Thanks, I applied the modification. (Remember to append 
"|| die" to each make, or make will not stop even though
make failed) I'll leave XEmacs part to xemacs herd.

(In reply to comment #12)
> Thanks, I applied the modification.

17 Oct 2004; Mamoru KOMACHI <usata@gentoo.org> gnuplot-4.0-r1.ebuild:
  Detects XEmacs correctly; bug #66765.

Assuming fixed, please reopen if this bug was closed incorrectly.