Bug 351571 - need fonts-{assamese,marathi,nepali,urdu} metapackages
Summary: need fonts-{assamese,marathi,nepali,urdu} metapackages
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: fonts-indic
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Rahul Bhalerao
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-25 01:14 UTC by Jens Petersen
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-30 02:39:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jens Petersen 2007-10-25 01:14:04 UTC
Description of problem:
The Assamese package group currently uses fonts-bengali as a metapackage
but it would get removed if Bengali support it uninstalled.
There should be a separate meta-package for Assamese which requires
lohit-fonts-bengali.

Comment 1 Jens Petersen 2007-10-25 03:13:38 UTC
same problem for Marathi, Nepali and Urdu

Comment 2 Rahul Bhalerao 2007-10-25 04:38:12 UTC
Should we also consider adding lohit-fonts-{assamese, marathi, nepali, urdu}?
This may help in maintaining language specific features of the fonts. 

Comment 3 Jens Petersen 2007-10-25 07:12:03 UTC
(In reply to comment #2)
> Should we also consider adding lohit-fonts-{assamese, marathi, nepali, urdu}?
> This may help in maintaining language specific features of the fonts. 

I think better to wait until there are some actual differences in the fonts.

Comment 4 Nicolas Mailhot 2007-10-25 17:01:55 UTC
Why do you need all those metapackages? Fedora usual policy is to avoid
metapackages, package grouping should be done via comps group

I could understand creating some short-lived metapackages to ease transition
from the old fonts-*** rpms, but not going metapackage as a long-term solution

Comment 5 Parag AN(पराग) 2007-10-25 17:26:09 UTC
Metapackages got created to install all fonts for a particular language. Suppose
a user want to check/test how all available fonts looks for any language(say
hindi) then he just need to use
yum install fonts-hindi
this will pull all fonts rpms available for Hindi language.

I think that may take less lines in comps file instead to add all fonts rpms :)


Comment 6 Nicolas Mailhot 2007-10-25 17:45:35 UTC
Thats a very bad reason. The correct Fedora package grouping solution is comps
groups, the Fedora package management tools understand comps groups, our people
that work on package management target comps groups, metapackages sort of work
but will never work completely because they're not supposed to be used.

If you push metapackages just to avoid the "hassle" of the official Fedora
package grouping method you're doing everyone a huge disservice.

If you don't believe me ask FPC or Fesco for an official ruling.

Comment 7 Jens Petersen 2007-10-26 00:14:22 UTC
(In reply to comment #4)
> Why do you need all those metapackages?

Well the problem is the comps package mechanism is still pretty.
I think Jeremy Katz wants to think about ways to improve the situation
but that basically requires major changes in comps (yum).

Basically the current problem is that language groups list their fonts
requirements and some languages require the same fonts.  Then if one
of the language groups is uninstalled the shared font with the other
language will get removed.  Metapackages at least provides a mechanism
to workaround this problem.

But now that we install most fonts by default anyway perhaps fonts
don't need to be listed in language groups as much as before.

We also introduced them for scim for the same reason.
Again a possible solution may be to install scim support by default
again after all, like we in F7.  

> Fedora usual policy is to avoid metapackages,
> package grouping should be done via comps group

Actually metapackages are becoming more common in Fedora
and I don't really understand the aversion to them: in some
cases they seem to be very useful.

> I could understand creating some short-lived metapackages to ease transition
> from the old fonts-*** rpms, but not going metapackage as a long-term solution

My long term plan is also to try to get rid of the metapackages,
but not before there is something better that can replace them.

Comment 8 Nicolas Mailhot 2007-10-26 08:25:51 UTC
(In reply to comment #7)
> (In reply to comment #4)
> > Why do you need all those metapackages?
> 
> Well the problem is the comps package mechanism is still pretty.
> I think Jeremy Katz wants to think about ways to improve the situation
> but that basically requires major changes in comps (yum).

There is always room for improvement in our packaging tools, that's not new

> Basically the current problem is that language groups list their fonts
> requirements and some languages require the same fonts.  Then if one
> of the language groups is uninstalled the shared font with the other
> language will get removed.

This is not a common case - most often users install the language groups sets
they need and never remove them

> Metapackages at least provides a mechanism
> to workaround this problem.

And make it impossible for a user to uninstall part of the metapackage set, and
creep in other package deps, and generally speaking kill most of the benefits of
splitting packages. Additionaly metapackages block spins from making different
grouping choices based on their target audience and space constraints.
 
> But now that we install most fonts by default anyway perhaps fonts
> don't need to be listed in language groups as much as before.

Please forget this argument. Even if metapackages stay you'll have to document
fonts in comps properly because defaults are only defaults, users are allowed to
make other choices, and if you don't have fine-grained package lists in comps
they can't do them in our GUI tools.

> We also introduced them for scim for the same reason.
> Again a possible solution may be to install scim support by default
> again after all, like we in F7.  
> 
> > Fedora usual policy is to avoid metapackages,
> > package grouping should be done via comps group
> 
> Actually metapackages are becoming more common in Fedora
> and I don't really understand the aversion to them: in some
> cases they seem to be very useful.

Metapackages are quick hacks that can help doing short-term workarounds, they
have lots of drawbacks and are an absolute pain to get rid of later. I though
that was well understood but since it's not the case I'll ask FPC to make
official guidelines on their use.


Comment 9 Jens Petersen 2007-10-30 02:39:24 UTC
(In reply to comment #8)
> > Basically the current problem is that language groups list their fonts
> > requirements and some languages require the same fonts.  Then if one
> > of the language groups is uninstalled the shared font with the other
> > language will get removed.
> 
> This is not a common case - most often users install the language groups sets
> they need and never remove them

Maybe, but it is nevertheless an intrinsic limitation of current
package system and something should be done about it IMHO since it
is a general problem for packages listed in more than one group.

> Even if metapackages stay you'll have to document fonts in comps properly
> because defaults are only defaults, users are allowed to make other choices,
> and if you don't have fine-grained package lists in
> comps they can't do them in our GUI tools.

I have replaced most of the metapackages in comps-f9 with
the actual fonts lists.

> Metapackages are quick hacks that can help doing short-term workarounds, they
> have lots of drawbacks and are an absolute pain to get rid of later. I though
> that was well understood but since it's not the case I'll ask FPC to make
> official guidelines on their use.

I don't encourage the widespread use of metapackages,
but in certain limited circumstances they can be useful I believe.
Having some guidelines about that written down would be nice.

Anyway let's work towards dropping the fonts metapackages soon then.


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