Red Hat Bugzilla – Bug 162952
conflicts between attempted installs of xemacs-sumo-el-20050505-4.1 and mew-xemacs-4.2-1
Last modified: 2007-11-30 17:11:09 EST
Description of problem: Upgrading a fully installed FC3 to FC4 with Extras enabled generates a couple dozen of messages like error: file /usr/share/xemacs/xemacs-packages/lisp/mew/mew-addrbook.elc conflicts between attempted installs of xemacs-sumo-20050505-4.1 and mew-xemacs-4.2-1 Version-Release number of selected component (if applicable): xemacs-sumo-el-20050505-4.1 mew-xemacs-4.2-1 How reproducible: always Steps to Reproduce: 1.Take an FC3 system (or earlier) with these two packages installed 2.Try to upgrade against a Fedora Extras repo 3. Actual results: The two packages conflict, upgrades fail. Expected results: Either both should be installable (they are both in Fedora Extras 4), or one should obsolete the other. Additional info: I didn't know whether this is a bug in xemacs-sumo or mew, so I filed it in xemacs-sumo and Cced the maintainer of mew. Feel free to move it to mew if this is the better place.
I'm not quite sure how and how much mew is maintained in xemacs-sumo. actually which version of mew does xemacs-sumo include?
$ rpm -q --provides xemacs-sumo | grep mew mew-xemacs = 1.94.2 Yep, that's old. But just a friendly note: it appears that the separate mew-xemacs package has entered Extras without much testing at all, as it's not installable when xemacs-sumo is installed (and xemacs-sumo is required by xemacs, albeit not xemacs-nox). In order to not drop functionality, I had to revert back to using the bundled apel, mew, and skk in xemacs-sumo when XEmacs moved to Extras, and I used the information available back then for the Obsoletes, see "rpm -q --obsoletes xemacs-sumo". If you want to keep maintaining mew-xemacs separately, that's very much fine with me, I can drop it from xemacs-sumo again. I assume the vast majority of XEmacs users would be happy with a slightly smaller xemacs-sumo, too. Your thoughts? By the way, if apel and ddskk (hi Jens!) ever get moved from Core to Extras, and their -xemacs subpackage is enabled again, we'll need to resolve a similar conflict with them as well.
Yes, I'd provide the latest one because that's too old and I don't think that it works properly now -- due to the lack of the backend application -- also, may be including the problems. Please drop it from xemacs-sumo again. Thanks.
Hi Ville, thanks and sorry for this hassle... :) There no longer seem to be any reason to have apel in Core so it should be moved to Extras too IMO. I will import ddskk into Extras soon. :)
Ok, I see ddskk is in Extras CVS now. I'll drop the upstream mew and skk packages (and Obsoletes) from xemacs-sumo. I think the best I can do is to just drop them and add no "Requires: {ddskk,mew}-xemacs" though, otherwise (assuming we don't cheat ;)) we'd have a chicken-egg build problem in the unbundled mew-xemacs and ddskk-xemacs. I've also asked upstream whether new Sumos are due to be released soon; if they are, I'll wait for that.
I've imported apel into Extras too, FYI.
I'm afraid we have a problem with that. Many packages in xemacs-sumo need apel in order to function correctly, so unlike for ddskk and mew, I would need to add "Requires: apel-xemacs" back to xemacs-sumo. However, I'm pretty certain that one cannot build apel-xemacs correctly without having xemacs-sumo (or to be more precise, the fsf-compat and xemacs-base XEmacs packages) installed. The build of apel depends heavily on things installed at build time in the sense that they should be more or less exactly the same as in the runtime environment. So, we have a chicken-egg build problem in apel-xemacs; I'd suggest solving it by just disabling the apel-xemacs subpackage in apel, at least for now. Your thoughts?
Ok, I see. will disable apel-xemacs in apel.
Ok, but what is the longer term solution? Remove apel from sumo's and re-enable apel-xemacs? I have a feeling that at least of the other elisp packages that needs apel needs a newer version than the one in sumo. At least wl seems to, but that hasn't been added to Extras yet.
erm, updating sumo's apel should works for that case, I suppose. apel in sumo can't be removed since other elisp packages depends on apel as Ville said at comment #7. I'm feeling that the elisp packages in sumo isn't maintaining well. so it's an good time to update the whole elisp packages anyway :)
Yep, there are some packages in the sumo that lag behind upstream, but on the other hand, many of them have been specifically tweaked to work with XEmacs. apel is particularly troublesome as it doesn't currently fit well in the XEmacs packages tree due to "too much" stuff being decided at compile time, and the infrastructure to distribute source only packages (from XEmacs folks POV) isn't there yet. And so it's somewhat frowned upon upstream. I'm an XEmacs committer, and the way I work is that all updates except for critical bugfixes go upstream first, and appear in the xemacs-sumo packages when upstream releases the next one. IOW, under usual circumstances, I'm inclined not to update any subpackages in xemacs-sumo solely for the FE distribution. Anyway, the conflict problem should be fixed in 20050715-1, and we should probably continue other parts of this discussion elsewhere if need be.