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.