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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
