Bug 507292

Summary: [RFE] Allow wildcards/regexps in rpm deps
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: rpmAssignee: Fedora Packaging Toolset Team <packaging-team>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: ffesti, fonts-bugs, james.antill, lkardos, n3npq, nicolas.mailhot, pinto.elia, pmatilai, rvokal, tcpip4000
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---Flags: lkardos: needinfo? (nicolas.mailhot)
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-11 08:41:28 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Nicolas Mailhot 2009-06-22 04:23:12 EDT
(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
Comment 1 Jeff Johnson 2009-06-22 15:26:17 EDT
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.
Comment 2 Nicolas Mailhot 2009-06-22 15:51:52 EDT
(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
Comment 3 Jeff Johnson 2009-06-22 16:14:15 EDT
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.
Comment 4 Nicolas Mailhot 2009-06-22 17:09:54 EDT
(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.
Comment 5 Jeff Johnson 2009-06-22 17:41:55 EDT
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!
Comment 6 Nicolas Mailhot 2009-06-23 04:58:52 EDT
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
Comment 7 Nicolas Mailhot 2009-06-23 05:01:27 EDT
(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?)
Comment 8 Jeff Johnson 2009-06-23 09:41:59 EDT
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.
Comment 9 devzero2000 2010-11-22 05:56:39 EST
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.
Comment 10 Fedora Admin XMLRPC Client 2012-04-13 19:08:45 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora Admin XMLRPC Client 2012-04-13 19:11:56 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Ľuboš Kardoš 2016-03-04 04:06:08 EST
Couldn't rich dependencies be utilized somehow for solving this problem?
Comment 13 Ľuboš Kardoš 2016-03-11 08:41:28 EST
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.