I have a breakfast package that Requires toast, bacon, and eggs. Importantly, breakfast needs exactly one eggs implementation to be a balanced meal.
The scrambled-eggs package Provides eggs. So does the fried-eggs package. In no circumstance should scrambled-eggs be installed alongside fried-eggs, even in the absence of breakfast.
If there were only two ways to prepare eggs, the solution would be to add Conflicts: fried-eggs to the scrambled-eggs package and vice versa. However, there are many ways to prepare eggs, some of which aren't even known yet, and a new way of preparing eggs might not be familiar with all of the other ways to prepare eggs.
Interestingly, it seems that for RPM version 4.11.3, you can make each package have both Provides: eggs and Conflicts: eggs, but this behavior does not seem to be documented. In fact, the documentation seems to suggest that it should not work:
Conflicts are basically inverse Requires. If there is a matching package the package cannot be installed. It does not matter whether the Conflict: tag is on the already installed or to be installed package.
Can I rely on the above Provides/Conflicts behavior for future versions of RPM? Or, how else can I solve this problem?
Simple answer:
It's not about "functionality".
"Provides - usually lists which files are provided (full path) and "tags" (toast, bacon, egg) are included. "Tags" (let's interpret it this way) SHOULD be unique to something very specific, not the functionality like MTA's or so.
You get conflicts, when multiple versions of packages of same name are not allowed or "Provides" match.
Basically, you SHOULD NOT interpret "provides" as "functionality". That's the idea.