[Fedora-packaging] Rules for obsoleting or conflicting packages

Toshio Kuratomi a.badger at gmail.com
Sun Oct 14 00:47:43 UTC 2012


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.

> 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.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20121013/588c6875/attachment.sig>


More information about the packaging mailing list