(this is mostly a yum-level RFE, but it would be nice if we kept the same depsolving logic in both apps) 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 database 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 deps like (dejavu|*|el) work in rpm (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
FYI: Permitting a '*' wild card in Requires: version/release with the well-defined semantic Match everything else (i.e. return 0 from rpmvercmp) is quite straightforward and handles most of what is commonly desired without the implementation cost (and semantic definitions) that need to be defined for a full blown *RE dependency matching compatible with existing legacy RPM and *.rpm implementations. For the record: Attaching new interpretations to a '*' character will be treated by older RPM implementations as any other non-alpha, non-digit, punctuation character would be treated. If the '*' is permitted only at the end of release/version, then legacy rpm would treat the '*' when encountered just like any pucnctuation character like '.' or "+". Since the character is at the end of the comparison, adding a well-defined Return 0 == match from rpmvercmp is almost certainly not change any prior comparison. I'll leave it to you to guess where an implementation for '*" wildcarding in dependency comparisons might be found. And having RE's on Provides: is exactly the same effect as adding multiple Provides:. Write a macro if you want a compact way to generate multiple alternative Provides: without the bother of typing separate Provides:. That just isn't that hard to do, nor is there any need to invent alternate Provides: syntax that forces rpm to implement regexp EVR comparison that I'm aware of.
(In reply to comment #1) > And having RE's on Provides: is exactly the same effect as adding multiple > Provides:. Generating multiple provides is trivial. For a very common font such as DejaVu Sans, for example, which exports two names, 7 faces, and 185 languages, that would mean generating 4463 Provides instead of one And that's assuming we never expose other parameters (such as default CSS family) in the packaging
There's no particular reason why all the multiple explicit font attributes need to be re-mapped into Provides:. For starters, generating multiple Provides:, even if *lots* of those provides are generated and never used, really hurts nothing but Bloat! Requires: is where the real pain with dependencies starts. But if you order the most important criteria according to what is likely top be used by packagers, then a trailing '*' wild card achieves whatever you want. And with only a single Provides: with the same carefully ordered string. Or wait for RPM to change to implement RE's within EVR comparison. Bring your ice skates, Hell is slippery turf when frozen over.
(In reply to comment #3) > There's no particular reason why all the multiple > explicit font attributes need to be re-mapped into > Provides:. Please. I didn't remap all the explicit font attributes. There are 22 different attribute fields in opentype alone, not counting the OS/2, Panose, Type1, etc metadata fields that were defined before and that apps still use. I only wrote about the three main attributes people care about and that they commonly use to choose which font to install. *After* fontconfig massaged them to remove any redundant or useless info. If it was that easy to reduce the problem to "just generate a few atomic fields and be done" I wouldn't open this RFE. Modern font files are incredibly rich and compact data stores. They don't cost millions to create for nothing. And the tech evolution is to increase wealth of features in single font files, not to decrease it.
I'm well aware of the attributes of modern font families, having studied fonts privately as a very complex data set to automate dependency generation and classification for packaging usages. But this is about packaging dependencies, not font attributes. There's literally no compelling usage case to map every detail of font attributes into rpm dependencies. Can you do that? Sure you can. But its not gonna work for many reasons, not the least of which you've already reported *repeatedly* is that packagers are not using the font attribute dependency framework you have devised. And -- if the font dependency framework needs RE pattern matching implemented into RPM dependencies -- well, skate on bro! I've suggested the following as likelier to "work": 1) order your font attributes in a single string L -> R by "importance". Consider "importance" as that which is most likely to be used by packagers or easiest to automate. Yes, this will not be perfect, but some means to track fonts in packaging is better than no means to track font dependencies in packaing. 2) If you've chosen the L->R "importance" ordering carefully enough, then a trailing '*' wiild card (which is entirely feasible afaik, unlike full blown RE pattern matching, within existing EVR comparisons) will allow a single axis of comparison that will map from less specific to more specific. All depends on getting the L->R ordering correct. If you miss that, I suspect that font dependencies will be DOA. JMHO, YMMV, everyone's does. Have fun!
That wouldn't work, there are very different use cases that demand different attribute L->R (depending if the user knows the font name he wants, for example), and even if we could reduce to a single use case the main contributor to the dep complexity is the languages a font support and language preference ordering is definitely locale/user specific
(though as I wrote before, I'm not 100% convinced multi-attribute dep de-muxing needs to be done at the rpm level, though the need starts at the cli package manager level, and having yum & rpm process the same deps differently could be a problem, no?)
Well I hope you've brought your ice skates. Adding regexp's to existing RPM EVR dependency comparisons is unlikely to happen (beyond the trailing '*' that I've mentioned that you consider "de-muxing"). I've looked at the issues at length.
As a personal opinion I agree with comment 8. These days rpm should rather try to search for the unification of the algorithm for comparison with other versions of popular package managers such as DEB http://man.he.net/man5/deb-version. See for example the request to introduce the "~" in the rpm version/release by Suse http://www.rpm.org/ticket/56 http://www.rpm.org/wiki/Problems/RPMSummitOSC09 Unfortunately it is not yet defined the semantics that "~" should have, but I disgress here.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Couldn't rich dependencies be utilized somehow for solving this problem?
As I wrote, we have support for rich deps in rpm now and we don't plan to implement wildcards or regexps in deps. I am closing this as wontfix.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days