We're currently pretty draconian about Conflicts: http://fedoraproject.org/wiki/Packaging:Conflicts
We basically have a whitelist of reasons that Conflicts are acceptable in Fedora. Anything else is not allowed until we evaluate it. I ran into another reason to think about adding to the whitelist recently: using Conflicts to install exactly 1 of N subpackages (Zabbix package which can be compiled to use one of postgres, mysql, or sqlite for different use cases and sites). These situations could be worked around, sometimes with invasive patching, to install to separate filesystem paths and using alternatives to make things work (although, like in this case, there might not be a tool to migrate a user's data if alternatives is run after the system has been in use for a while.)
Weighed against this is precisely what benefit we're getting out of stopping the use of Conflicts. The reasons stated previously was so that yum install '*' might work. We already allow enough Conflicts in the distro that that seems to be pretty hopeless: http://smoogespace.blogspot.com/2011/05/doing-everything-install.html
The Guideline page says that the errors that the user receives from trying to install conflicting packages does not give any hint to the user about what to do about the situation which is true:
{{{ Resolving Dependencies --> Running transaction check ---> Package generic-release.noarch 0:14-1 set to be installed --> Processing Conflict: generic-release-14-1.noarch conflicts fedora-release --> Finished Dependency Resolution Error: generic-release conflicts with fedora-release-14-1.noarch }}}
Finally, I have found that people often reach for Conflicts as the simplest solution when other solutions might be more appropriate.
The open question would be how much labor do we wish to demand that packagers do to avoid Conflicts for the benefits that we derive from them. Would we consider downgrading this to a should (so that the whitelist becomes merely examples of proper use of Conflicts)?
{{{ Conflicts to install exactly 1 of N subpackages (Zabbix package which can be compiled to use one of postgres, mysql, or sqlite for different use cases and sites). }}}
What do you mean here? You want to have zabbix-sqlite and zabbix-postgres etc. that conflict with each other? Why don't you just use alternatives, if you can't do it another way?
But if you don't want to do that for some reason, then I think the "no implicit conflicts" and "no conflicting files" reasons should allow you to use conflicts for this.
Don't know what was Ville's motivation for using the Conflicts instead of alternatives, but the "no implicit conflicts" and "no conflicting files" rules seems to be valid here (https://bugzilla.redhat.com/show_bug.cgi?id=494706).
Replying to [comment:2 james]:
"no implicit conflicts" doesn't allow you to use the Conflicts tag. It just says that you must never have implicit conflicts. The current guidelines setup the Conflicts tag as the last resort for certain specific circumstances (of which the current zabbix case is not currently listed). As you point out, alternatives is a possible way to do without Conflicts and the current guidelines would demand that alternatives (or some other method) be used rather than a Conflict tag. This is what I'm asking whether we still think it is sensible or not.
abadger1999 to link Conflicts guidelines to altrnatives and env-mod; need someone to expand conflicts benefits section.
Proposal to relax Conflicts is rejected.
And the specific case here could be whitelisted but only if it turns out that alternatives does not work for this case.
Login to comment on this ticket.