Bug 507292

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.

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