Red Hat Bugzilla – Bug 297431
blacklist evolution-devel from multilib
Last modified: 2014-03-16 23:08:35 EDT
Description of problem: Can evolution not be multilib for F8? I think it would be nice to blacklist evolution-devel unless there is a good reason not too?
Is there a good reason /to/ blacklist it? Blacklists are just hacks that have to be carried around in any tool that has a part in this. We generally only blacklist if there is a genuine problem with having it multilib.
What is the point of having evolution multilib? For F9 IMHO we should really stop having multilib trees IMHO and just let yum sort it out from the i386 and x86_64 repos for those that want it. Quite a number of Fedora people seem to agree that this is the right way to go.
Reasons to not multilib include it is installed by default on the desktop, it is pretty big, having it multilib seems meaningless, and it is a waste of bandwidth for updates and diskspace etc.
The plan is already to split things out for F9. However, adding more blacklists just because isn't the answer - it leads to unmaintainable lists.
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
evolution-devel still seems to be multilib in current pre-F9 rawhide.
There is multilib_policy if you want less multilib by default; I don't see logic as to how having it multilib specifically breaks anything, so I don't see a reason to change this in mash.