(this is the sister bug of ##507292 which was opened against rpm) The problem: Selecting a font is a multi-criterium operation. We need to match on font family, font style, language support, unicode support, etc. At any time all of just some of those selection criterii can be provided by the user or applications. To have features like font auto-installation work reliably, this matching needs to extend to the package installation selection logic Right now rpm is only allowing to specify atomic provides, so we can have a font package that Provides font(dejavusans) and Provides font(:lang=el) but there is no warranty both those provides are belonging to the same font. There is no way to distinguish between a package that includes an actual greek dejavusans and a package that includes a dejavusans greek-less file and another totally different greek font To workaround this rpm limitation we've been asking packagers to put font files belonging to different font families in different packages. However: 1. many still don't 2. it's not technically possible for all font formats, for example the ttc font format allows mixing of fonts with different characteristics in a single file The ideal solution: Ability to have Provides like: font(comma-separated font name list|comma-separated style list|comma-separated lang list) (rough mockup that probably needs refining) And have package selectors like (dejavu|*|el) that work in yum (yes a font can declare many different names, be available in many different styles, cover many different languages) For ttc files we'd then generate one Provides for each font included in the ttc bundle
See also bug #507294 opened against yum
> font(comma-separated font name list|comma-separated style list|comma-separated > lang list) (rough mockup that probably needs refining) Very much so, for instance given: font(bar,blah|foo,fu|lang=en,lang=el) ...you couldn't match the above for arbitrary points with just wildcards. > To have features like font auto-installation work reliably, this matching needs > to extend to the package installation selection logic I think what you want to do is put all this inside some PK API. So the provides would look something like: Provides: font(dejavusans:style=bar:lang=el) ...then PK just looks through font(dejavusans*) or whatever. Because I don't think anyone is going to be running "yum install font(dejavusans:*:lang=el)" or whatever from the cmd line. Obviously if rpm decides to start processing wildcards on requires, then we'll have to follow along for the ride ... but that doesn't seem like the best solution (and I'm going to guess rpm isn't going to do that). Doing wildcards on the install cmd line, is certainly possible ("yum provides" does them) ... I'm just not sure how awesome an idea that is, and I don't see a usecase.
(In reply to comment #2) > > font(comma-separated font name list|comma-separated style list|comma-separated > > lang list) (rough mockup that probably needs refining) > > Very much so, for instance given: > > font(bar,blah|foo,fu|lang=en,lang=el) > > ...you couldn't match the above for arbitrary points with just wildcards. yep sure, the point is, I don't really care how it ends up looking like, the main need is to be able to group properties in some way. It may be that the only way to do it reliably is to pass on wildcards and go regexp. Or standardise the way multi-valued provides are written, so simple wildcards can be processed in consistent ways regardless of the namespace. Maybe something like: namespace(label1:list-of-values|label2:list-of-values) etc ? font(family:bar,blah|style:foo,fu|lang:en,fr,el) > > To have features like font auto-installation work reliably, this matching needs > > to extend to the package installation selection logic > > I think what you want to do is put all this inside some PK API. So the > provides would look something like: To be honest I'm not really sure about the need to have rpm understand this syntax (I suspect someone would find uses for it, for example we could add a dep to the fontconfig package on font(style=regular|lang=en) to make sure we always install at least one fallback font by default) but I'm quite sure it should be exposed at the yum level at least. Having apps auto-install fonts when they find the need in a document is great, but sometimes users want to install fonts before they've started typing their document :p. > Because I don't > think anyone is going to be running "yum install font(dejavusans:*:lang=el)" or > whatever from the cmd line. Actually, I'm quite sure people will do. The internet is littered with yum recipes to install particular fonts (either "here is how to install dejavu lgc", or "here is how to install every available thai font"). They're all brittle and break from release to release because packages get renamed, fonts get replaced, and people have to match on package names instead of what they really want (a particular font, or fonts for a language, etc) Now, I know the functional need, but I don't know actual rpm/yum/pk innards, so I'm not the best person to suggest how the technical part should look like. So far we've done what the current tools made possible, but we're hitting tooling limitations.
> but I'm quite sure it should be exposed at the yum level at least. Having > apps auto-install fonts when they find the need in a document is great, > but sometimes users want to install fonts before they've started typing > their document Then open-office writer can hook in and ask to install some fonts. Or people can just look for a font name they recognise in PK or yum. I find it really hard to believe people are going to think "Oh, I need to write a document. Oh I don't have any fonts. Oh let's just install all English fonts with 'yum install fonts(*;lang=en;*)'. ". > Actually, I'm quite sure people will do. The internet is littered with yum > recipes to install particular fonts (either "here is how to install dejavu > lgc", or "here is how to install every available thai font"). You are implying that people need weird specific subsets, in the above two cases I'd suggest: yum install dejavu\* yum install \*-fonts
(In reply to comment #4) > > but I'm quite sure it should be exposed at the yum level at least. Having > > apps auto-install fonts when they find the need in a document is great, > > but sometimes users want to install fonts before they've started typing > > their document > > Then open-office writer can hook in and ask to install some fonts. Or people > can just look for a font name they recognise in PK or yum. I find it really > hard to believe people are going to think "Oh, I need to write a document. Oh I > don't have any fonts. Oh let's just install all English fonts with 'yum install > fonts(*;lang=en;*)'. ". just open google, the internet is full of yum install instructions for fonts also many new users do not know Linux font names, but they know how to type instructions taken from an howto > > Actually, I'm quite sure people will do. The internet is littered with yum > > recipes to install particular fonts (either "here is how to install dejavu > > lgc", or "here is how to install every available thai font"). > > You are implying that people need weird specific subsets, in the above two > cases I'd suggest: > > yum install dejavu\* This will work for dejavu because the package has sane naming. It won't work for other fonts > yum install \*-fonts That won't help to install 'all greek fonts" available for example, which is what people do (replace greek with any langage)
we have another bug to do the entire opposite - allow wildcards inside rpm prcos which are NOT wildcards but passed down the stack cleanly. At this point I think yum will do what rpm does. when rpm decides - reopen.