Bugzilla Bug 177936

* checking 19 files for package collisions
existing file /usr/bin/gnuclient is not owned by this package
existing file /usr/bin/gnuattach is not owned by this package
existing file /usr/bin/gnudoit is not owned by this package
existing file /usr/share/man/man1/gnuserv.1.bz2 is not owned by this package
existing file /usr/share/man/man1/gnuclient.1.bz2 is not owned by this package
existing file /usr/share/man/man1/gnuattach.1.bz2 is not owned by this package
existing file /usr/share/man/man1/gnudoit.1.bz2 is not owned by this package
* This package is blocked because it wants to overwrite
* files belonging to other packages (see messages above).
* If you have no clue what this is all about report it 
* as a bug for this package on http://bugs.gentoo.org

package app-emacs/gnuserv-3.12.7 NOT merged

Searching all installed packages for file collisions...
Press Ctrl-C to Stop

 * app-editors/xemacs-21.4.20-r3:

     '/usr/bin/gnuclient'
     '/usr/bin/gnuattach'
     '/usr/bin/gnudoit'
     '/usr/share/man/man1/gnuserv.1.bz2'
     '/usr/share/man/man1/gnuclient.1.bz2'
     '/usr/share/man/man1/gnuattach.1.bz2'
     '/usr/share/man/man1/gnudoit.1.bz2'

Since these are probably the same files (gnu{serv,client}* from XEmacs are also
version 3.12, all man pages are identical), it should not be a big problem.

Possible (IMHO bad) solutions:
- emacs.eselect could handle it, the XEmacs part being no problem.
  But I am very reluctant to add another special case for gnuserv.
- alternatives.eclass, but then XEmacs would have to use both emacs.eselect
  and alternatives.eclass. Ugly.

Any better ideas?

It looks like the XEmacs versions have also seen independant development, so
even if the man pages are the same this probably doesn't apply to the binaries.
I have no idea if they are (meant to be) compatible.

I think it's funny that XEmacs with its modular approach has this stuff as part
of the main distribution, while GNU Emacs with its monolithic approach has this
as a separate package. :-)

If I understand the alternatives solution correctly, then the xemacs build
should install this stuff with an -xemacs postfix, and then deal with the
correct symlink through the alternatives stuff. It looks like this is designed
to work within a single package with slots. So does this mean that for Emacs
and XEmacs the last one wins?

At least it will fix the file-collisions...

(In reply to comment #1)
> So does this mean that for Emacs
> and XEmacs the last one wins?

Ok, that's unclear: I meant to say "the last one that gets installed".

(In reply to comment #1)
> It looks like the XEmacs versions have also seen independant development,
> so even if the man pages are the same this probably doesn't apply to the
> binaries. I have no idea if they are (meant to be) compatible.

Hm, the app-emacs/gnuserv binaries are the ones from XEmacs 21.5.17. I don't
know how this version relates to 21.4.20 (older or newer?) but the differences
for gnuserv appear to be tiny, and they should be compatible.

> I think it's funny that XEmacs with its modular approach has this stuff as
> part of the main distribution, while GNU Emacs with its monolithic approach
> has this as a separate package. :-)

GNU Emacs includes emacsclient which has similar functionality.

> If I understand the alternatives solution correctly, then the xemacs build
> should install this stuff with an -xemacs postfix, and then deal with the
> correct symlink through the alternatives stuff. It looks like this is designed
> to work within a single package with slots. So does this mean that for Emacs
> and XEmacs the last one wins?

(In reply to comment #2)
> Ok, that's unclear: I meant to say "the last one that gets installed".

Fortunately not. The order of the arguments of alternatives_makesym determines
which one is preferred.

However, alternatives.eclass doesn't support compression suffixes, so its use
is clumsy for man pages. Look at emacs-21.4-r8.ebuild, function
update-alternatives() for an example. The newer Emacs ebuilds don't use it
anymore.

I'm still not sure what would be the best path to follow here. We could also
split off the colliding files from app-emacs/gnuserv to a separate package
(with blocking dep on xemacs) and have || ( app-emacs/gnuserv-whatever
virtual/xemacs ) as dependency in gnuserv. But maybe the problem is not worth
the effort.

(In reply to comment #3)

> Hm, the app-emacs/gnuserv binaries are the ones from XEmacs 21.5.17. I don't
> know how this version relates to 21.4.20 (older or newer?) but the differences
> for gnuserv appear to be tiny, and they should be compatible.

XEmacs 21.5 is the new branch on which all development happens. XEmacs 21.4.x
is in maintenance mode only. So 21.5 is newer than 21.4, irrespective of
release date.

> GNU Emacs includes emacsclient which has similar functionality.

Aha. So that begs the question why there is a separate package as well, since
emacsclient seems to do the same thing. Perhaps we don't need
app-emacs/gnuclient in the tree?

> I'm still not sure what would be the best path to follow here. We could also
> split off the colliding files from app-emacs/gnuserv to a separate package
> (with blocking dep on xemacs) and have || ( app-emacs/gnuserv-whatever
> virtual/xemacs ) as dependency in gnuserv. But maybe the problem is not worth
> the effort.

I'm afraid that this issue is not high priority for me, so I'm not going to
press a solution at this time. If you come up with something that you are happy
with then please feel free to suggest/implement it. :-) 

Otherwise I'm sure I'll revisit it when my other XEmacs problems are solved.

(In reply to comment #4)
> I'm afraid that this issue is not high priority for me,

Look at the "Priority" and "Severity" fields. ;)

> so I'm not going to press a solution at this time. If you come up with
> something that you are happy with then please feel free to suggest/implement
> it. :-) 

I think we are going to seek a solution on the app-emacs/gnuserv side.

(In reply to comment #3)
> We could also split off the colliding files from app-emacs/gnuserv
> to a separate package (with blocking dep on xemacs) and have
> || ( app-emacs/gnuserv-whatever virtual/xemacs ) as dependency in gnuserv.

Solution taken:
- Programs and man pages split off to new package app-emacs/gnuserv-programs,
  blocking app-editors/xemacs
- app-emacs/gnuserv installs only elisp files and rdepends on
  || ( ~app-emacs/gnuserv-programs-${PV} app-editors/xemacs )
- gnuserv.el patched so that it can find also the XEmacs gnuserv binary in
  /usr/lib/xemacs-*

Available for testing in the Emacs overlay.

Committed to Portage tree.

See bug #180292 for the keywording.