[Fedora-packaging] Rules for obsoleting or conflicting packages

[Michael Schwendt]

On Sat, 13 Oct 2012 17:47:43 -0700, Toshio Kuratomi wrote:

> On Sat, Oct 13, 2012 at 09:10:24PM +0200, Mario Blättermann wrote:
> > Hi all,
> > 
> > I'm currently reviewing the following package:
> > https://bugzilla.redhat.com/show_bug.cgi?id=865535
> > 
> > The package python-datanommer-models seems to be a splitout from
> > datanommer, that's why we have currently:
> > 
> > Conflicts:      datanommer < 0.2.0
> > 
> > In my mind, it should be "Obsoletes" instead of "Conflicts" because it
> > is the successor of datanommer. But we have a somewhat more difficult
> > scenario here. The packager writes:
> > 
> > "Regarding the Conflicts/Obsoletes/Provides, I'd like to still maintain
> > the datanommer package itself as a kind of meta-package that installs
> > the splitoffs but also includes "fedmsg-hub" which will turn on a new
> > service.  Once these packages are approved, I would bump the datanommer
> > meta package from 0.1.8 to 0.2.0 to match them."
> > 
> So in that visualization of the problem, the versioned Conflicts makes more
> sense than Obsoletes.

Questionable. Conflicts are evil, even if they are only temporary.
https://fedoraproject.org/wiki/Packaging:Conflicts

There's also the "Package Renaming Process".
https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required

Current "datanommer" package in koji includes a couple of Python modules,
two of them are included also in the new python-datanommer-models package:
"datanommer" and "datanommer.models". Hence this is a rename. 
Moving the modules to a different package without adding Obs/Prov isn't
nice.

"repoquery --whatrequires datanommer" returns nothing. Koji tells that
this package is so brand-new, it's updates-testing *only*. With several
releases since 2012-09-26 not having reached "stable" at all.

> > Could we split out the appropriate files from datanommmer instead,
> > throwing away the new review request? Means, we have a "datanommer" base
> > package which is a metapackage only with some common files, which pulls
> > the needed dependencies. Any ideas for a convenient solution while
> > keeping a proper upgrade path?
> > 
> This sounds like it would also be possible, though.  If this is what's done,
> there's likely no need to mess with Conflicts and obsoletes at all.

Add _versioned_ (!) Obsoletes/Provides, please, as suggested by Mario
during package review already. Due to the version the two packages can
coexist.