[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