Bug 162952 - conflicts between attempted installs of xemacs-sumo-el-20050505-4.1 and mew-xemacs-4.2-1
conflicts between attempted installs of xemacs-sumo-el-20050505-4.1 and mew-x...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xemacs-sumo (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-11 16:12 EDT by Axel Thimm
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 20050715-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-31 07:08:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Axel Thimm 2005-07-11 16:12:47 EDT
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.
Comment 1 Akira TAGOH 2005-07-11 20:49:00 EDT
I'm not quite sure how and how much mew is maintained in xemacs-sumo. actually
which version of mew does xemacs-sumo include?
Comment 2 Ville Skyttä 2005-07-12 13:44:21 EDT
$ 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. 
Comment 3 Akira TAGOH 2005-07-12 20:50:30 EDT
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.
Comment 4 Jens Petersen 2005-07-12 22:23:50 EDT
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. :)
Comment 5 Ville Skyttä 2005-07-13 10:24:34 EDT
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. 
Comment 6 Akira TAGOH 2005-07-19 00:50:54 EDT
I've imported apel into Extras too, FYI.
Comment 7 Ville Skyttä 2005-07-19 10:13:24 EDT
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? 
Comment 8 Akira TAGOH 2005-07-19 20:41:22 EDT
Ok, I see. will disable apel-xemacs in apel.
Comment 9 Jens Petersen 2005-07-20 05:11:27 EDT
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.
Comment 10 Akira TAGOH 2005-07-20 07:25:28 EDT
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 :)
Comment 11 Ville Skyttä 2005-07-31 07:08:29 EDT
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.  

Note You need to log in before you can comment on or make changes to this bug.