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
(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:
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.