* 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.
*** Bug 501452 has been marked as a duplicate of this bug. ***
*gnuserv-3.12.8-r1 (15 Feb 2014) 15 Feb 2014; Ulrich Müller <ulm@gentoo.org> +gnuserv-3.12.8-r1.ebuild: Recent XEmacs includes a gnuserv that is no longer compatible with this standalone version. Install binary programs, instead of splitting them off to app-emacs/gnuserv-programs. Add blockers against that package and against app-editors/xemacs. As was to be expected, things have diverged, so the gnuserv binaries from XEmacs don't work with the elisp code of the app-emacs/gnuserv package any more. Therefore we cannot keep the previous solution. For the time being, I've added a blocker between app-editors/xemacs and app-emacs/gnuserv. Any better suggestion? eselect won't help here, because the binaries are incompatible with each other. Renaming the programs also doesn't look very attractive.
(In reply to Ulrich Müller from comment #9) > eselect won't help here, because the binaries are incompatible with each > other. Thinking about it again, an eselect based solution would be possible. Of course, /usr/bin/gnuclient would work only with the eselected flavour (FSF GNU Emacs or XEmacs). For the other Emacs flavour, an explicit gnuclient-emacs or gnuclient-xemacs would have to be used. I think this is still preferable to a blocker. So the plan would be to add a gnuclient module to eselect-emacs, and have app-editors/xemacs and app-emacs/gnuserv install their binaries and manpages with an -xemacs and -emacs suffix, respectively. @matsl: Any opinion? This would be similar to what we already do for ctags and etags. If you don't object, I would take care of updating the xemacs ebuilds, too.
The eselect solution sounds fine to me. Feel free to update the xemacs ebuilds. That will be appreciated. Thanks.
+*xemacs-21.5.34-r2 (17 Feb 2014) +*xemacs-21.4.22-r3 (17 Feb 2014) + + 17 Feb 2014; Ulrich Müller <ulm@gentoo.org> +xemacs-21.4.22-r3.ebuild, + +xemacs-21.5.34-r2.ebuild: + Install gnuserv binaries with -xemacs suffix to avoid file collisions with + app-emacs/gnuserv; active versions of gnuclient and gnudoit can now be + selected with the gnuclient eselect module, bug 177936. +
+*gnuserv-3.12.8-r2 (17 Feb 2014) + + 17 Feb 2014; Ulrich Müller <ulm@gentoo.org> -gnuserv-3.12.8-r1.ebuild, + +gnuserv-3.12.8-r2.ebuild, +files/50gnuserv-gentoo-3.12.8-r2.el, + +files/gnuclient.desktop: + Install binaries with -emacs suffix to avoid file collisions with XEmacs; + active versions of gnuclient and gnudoit can now be selected with the + gnuclient eselect module, bug 177936. Install the gnuserv binary under + /usr/libexec and set the path in the site-init file accordingly. Install a + desktop entry with USE=X. + Package masked for testing: =app-admin/eselect-ctags-1.15 =app-admin/eselect-emacs-1.15 =app-editors/xemacs-21.4.22-r3 =app-editors/xemacs-21.5.34-r2 =app-emacs/gnuserv-3.12.8-r2 I shall unmask these revisions in a few days from now.
(In reply to Ulrich Müller from comment #13) > I shall unmask these revisions in a few days from now. Unmasked today already. (According to my tests, everything should be fine, and the packages won't get much testing by users if they stay masked.) @Juergen: Thanks for reporting this in bug 501452. The blocker was not a good idea indeed.
(In reply to Ulrich Müller from comment #14) > (In reply to Ulrich Müller from comment #13) > > I shall unmask these revisions in a few days from now. > > Unmasked today already. (According to my tests, everything should be fine, > and the packages won't get much testing by users if they stay masked.) > > @Juergen: Thanks for reporting this in bug 501452. The blocker was not a > good idea indeed. It was a pleasure for me to report this issue. Thanks for solving it. My personal solution until now was to uninstall all xemacs packages. But now I have a new issue connected with gnuserv. There is a conflict between app-emacs/gnuserv and app-emacs/gnuserv-programs. Therefore I uninstalled app-emacs/gnuserv: root@leopard:/root(29)# emerge -pvD app-emacs/gnuserv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-emacs/gnuserv-3.12.8-r2 USE="X" 0 kB [blocks B ] app-emacs/gnuserv-programs ("app-emacs/gnuserv-programs" is hard blocking app-emacs/gnuserv-3.12.8-r2) Total: 1 package (1 new), Size of downloads: 0 kB Conflict: 1 block (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (app-emacs/gnuserv-3.12.8-r2::gentoo, ebuild scheduled for merge) pulled in by app-emacs/gnuserv For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked root@leopard:/root(30)# qlist -Iv gnuserv app-emacs/gnuserv-programs-3.12.8-r1 root@leopard:/root(31)# qlist -v gnuserv-programs /usr/share/man/man1/gnuclient.1.bz2 -> gnuserv.1.bz2 /usr/share/man/man1/gnuattach.1.bz2 -> gnuserv.1.bz2 /usr/share/man/man1/gnudoit.1.bz2 -> gnuserv.1.bz2 /usr/share/man/man1/gnuserv.1.bz2 /usr/bin/gnuclient /usr/bin/gnuattach /usr/bin/gnuserv /usr/bin/gnudoit Now the problem is, that the gnuserv-compat elisp file is missed: root@orca:/root(19)# qlist -Iv gnuserv app-emacs/gnuserv-3.12.8-r2 root@orca:/root(20)# qlist -v gnuserv /usr/share/applications/gnuclient.desktop /usr/share/doc/gnuserv-3.12.8-r2/README.orig.bz2 /usr/share/doc/gnuserv-3.12.8-r2/ChangeLog.bz2 /usr/share/doc/gnuserv-3.12.8-r2/README.bz2 /usr/share/emacs/site-lisp/site-gentoo.d/50gnuserv-gentoo.el /usr/share/emacs/site-lisp/gnuserv/gnuserv.elc /usr/share/emacs/site-lisp/gnuserv/gnuserv-compat.elc /usr/share/emacs/site-lisp/gnuserv/devices.elc /usr/share/emacs/site-lisp/gnuserv/gnuserv.el /usr/share/emacs/site-lisp/gnuserv/gnuserv-compat.el /usr/share/emacs/site-lisp/gnuserv/devices.el /usr/share/man/man1/gnuserv-emacs.1.bz2 /usr/share/man/man1/gnudoit-emacs.1 /usr/share/man/man1/gnuclient-emacs.1 /usr/bin/gnudoit-emacs /usr/bin/gnuclient-emacs /usr/libexec/emacs/gnuserv app-emacs/gnuserv-3.12.8-r2 root@orca:/root(20)# qlist -v gnuserv /usr/share/applications/gnuclient.desktop /usr/share/doc/gnuserv-3.12.8-r2/README.orig.bz2 /usr/share/doc/gnuserv-3.12.8-r2/ChangeLog.bz2 /usr/share/doc/gnuserv-3.12.8-r2/README.bz2 /usr/share/emacs/site-lisp/site-gentoo.d/50gnuserv-gentoo.el /usr/share/emacs/site-lisp/gnuserv/gnuserv.elc /usr/share/emacs/site-lisp/gnuserv/gnuserv-compat.elc /usr/share/emacs/site-lisp/gnuserv/devices.elc /usr/share/emacs/site-lisp/gnuserv/gnuserv.el /usr/share/emacs/site-lisp/gnuserv/gnuserv-compat.el /usr/share/emacs/site-lisp/gnuserv/devices.el /usr/share/man/man1/gnuserv-emacs.1.bz2 /usr/share/man/man1/gnudoit-emacs.1 /usr/share/man/man1/gnuclient-emacs.1 /usr/bin/gnudoit-emacs /usr/bin/gnuclient-emacs /usr/libexec/emacs/gnuserv Any idea, how to handle this?
(In reply to Juergen Rose from comment #15) You should unmerge app-emacs/gnuserv-programs; it is not needed any more because the new gnuserv revision installs all necessary binaries, too. Then emerge app-emacs/gnuserv-3.12.8-r2. Optionally, app-editors/xemacs-21.4.22-r3 or app-editors/xemacs-21.5.34-r2 can be installed along with it. In this case, you can use "eselect gnuclient" to select the preferred flavour of gnuclient/gnudoit.
(In reply to Ulrich Müller from comment #16) > (In reply to Juergen Rose from comment #15) > > You should unmerge app-emacs/gnuserv-programs; it is not needed any more > because the new gnuserv revision installs all necessary binaries, too. app-emacs/gnuserv-programs was installed today first time as dependency of something. > Then > emerge app-emacs/gnuserv-3.12.8-r2. This works. > Optionally, app-editors/xemacs-21.4.22-r3 or app-editors/xemacs-21.5.34-r2 > can be installed along with it. In this case, you can use "eselect > gnuclient" to select the preferred flavour of gnuclient/gnudoit. Thanks Ulrich.
