Red Hat Bugzilla – Bug 244954
better handling of packages listed in multiple package groups
Last modified: 2014-01-21 17:58:37 EST
Description of problem:
I think this is a problem which is getting more common as more packages
are added to comps.
Example 1 (scim core packages)
In FC6 and RHEL5 if one removes a language group that includes scim
packages then scim core packages will get removed even though another
language group using scim is still "installed". (See bug 229742 and
bug 223975) For F7 we decided to install scim by default (IMHO a nasty
hack) to work around this (bug 229742). And currently for F8 I am
proposing to add language meta packages to scim to avoid having to
install scim by default for all desktop users (bug 244770).
Example 2 (fonts common to multiple languages)
dejavu-fonts, fonts-ISO8859-2, fonts-KOI8-R
These font packages are listed under more and than one language group
in comps, which means that if you install several of those language
groups and then uninstall one of them the font will be removed
even though another language group requiring that language is still
installed (according to pirut say). [This
I am sure there are other examples lurking in comps.
In short yum/pirut needs a more stronger notion of package groups
to give a consistent user experience. I am not sure what the best
way to provide this infrastructure is?
Right now groups are, more or less, just a list of pkgs with some odd
attributes to the pkgs. It sounds like the behavior you want is if the user does:
yum remove somefonts
Then yum will only remove 'somefonts' if nothing else in multiple comps groups
requires it? Is that right? If so then it feels fairly confusing to the user b/c
yum remove has always removed the pkg(s) asked for and all things that depend
Or are you suggesting something more like a way of groups of packages being able
to require a package and the group be a hard-boundary for the recursive-removal
(In reply to comment #1)
> Right now groups are, more or less, just a list of pkgs with some odd
> attributes to the pkgs.
> Or are you suggesting something more like a way of groups of packages
> being able to require a package and the group be a hard-boundary for
> recursive-removal lookup?
Yes I was hoping for something like this.
I'm not quite sure how we get there without breaking a lot of user expectations,
especially the somewhat more advanced users. Then again, I'm unclear about the
use case where someone is removing languages/fonts on a system. Is this a common
event? In my own experience I tend to just leave them alone, but then again I
don't do much with languages or fonts so mine may be a bad example.
Is there a use case you're seeing where the existing behavior is annoying?
Maybe it is more common for users of pirut.
Here are a couple more examples.
In FC6 and RHEL5:
# yum groupinstall hindi-support bengali-support
installs the common packages scim-m17n and scim-bridge-gtk needed for Indic input.
Later one then decides to uninstall Bengali support say:
# yum groupremove bengali-support
then those two packages are removed leaving a system where Hindi can no longer
be input. Above yum incantations could also be removed by the equivalent operations
in pirut of course.
Similarly, if one installs Russian and Ukrainian support and later removes
one of them one will lose fonts-KOI8-R, and similarly for Eastern European
languages fonts-ISO8859-2 will get removed.
I opened this bug to see if something can be done to avoid these kinds
of problems in the future.
The only real way to fix this is to stop doing groups as we do today and
completely rethink the way that package selection and discovery is done :-/
My feeling now is that meta-packages is probably the best answer to this
unless we really want to re-architect this completely.
Feel free to do with this bug what you want.
I actually do want to sit down and rework package selection and discovery.
The fact that we now have ~8000 packages of which ~2700 are listed in comps
means that we need to look again at how best to do things as what we're doing
now worked well when we had ~ 1500 of which ~500 were listed.
Is it okay to mark this as deferred b/c it seems like it fairly permanently is
Seems ok to me FWIW.
I'll move it then, however I do wonder "why would someone want to remove the
Is it just the name that would make people think, oh I don't need that so I
might as well remove it?
The other thing is I do have a patch, which I'll show around after Fed-9 is out
that let's people see how much of the groups are installed ... which might lean
expectations in a better direction for what groups are.
(In reply to comment #10)
> I'll move it then, however I do wonder "why would someone want to remove the
> bengali-support group"?
Well, fair question: it is probably a bit of an edge/corner case:
but basically this issue affects any package listed in multiple groups.
(Maybe we should just disable that for now, but that is not really practical
But to answer your specific question: there might be a number of reasons -
they might find the bengali font(s) covers their own script but they want
to use another font, or they just want to get rid of the bengali input maps
from the scim menu quickly or some unneeded langpacks.
(Anyway we already have a workaround in place for scim.)
> The other thing is I do have a patch, which I'll show around after Fed-9 is out
> that let's people see how much of the groups are installed ... which might lean
> expectations in a better direction for what groups are.
For F10 I would like to rethink language support groups a put and mostly
just fill them with optional packages - trying to install general fonts
and input methods by default.
Look forward to you patch anyway, thanks.