Rules for obsoleting or conflicting packages
 

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

Rules for obsoleting or conflicting packages
 

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

Rules for obsoleting or conflicting packages
 

On Sun, Oct 14, 2012 at 01:55:20PM +0200, Michael Schwendt wrote:
> 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
>
I'm reading that this is okay usage into this section:
http://fedoraproject.org/wiki/Packaging:Conflicts#Optional_Functionality

The package can work with the datanommer package if that package is >= 0.2.0
It will conflict if the datanommer package is less than 0.2.0.

> 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.
>
It's questionable to me whether this is a rename or not. The feedback that
Mario quotes about the packager's intention says that the packager is not
thinking of this as a rename. It seems that currently, the datanommer
application ships with several python modules. Some of those ae being moved
to their own package. But the datanommer package is going to continue to exist.
Installing the updated datanommer =will pull in the new python-datanommer-models
package via Requires. So in practical terms, people who have the datanommer
paackage installed will upgrade to the new datanommer and still have the
python modules because of the Requires: python-datanommer-models in the
updated datanommer package.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Rules for obsoleting or conflicting packages
 

On Sun, 14 Oct 2012 22:28:04 -0700, Toshio Kuratomi wrote:

> > > 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
> >
> I'm reading that this is okay usage into this section:
> http://fedoraproject.org/wiki/Packaging:Conflicts#Optional_Functionality

That's sad, if the guidelines allow so much room for interpretation.
The section is titled "Optional Functionality" and does not talk about
adding conflicts for libraries that are too old or too new. It even
specifically says to use Requires instead of Conflicts!

> The package can work with the datanommer package if that package is >= 0.2.0
> It will conflict if the datanommer package is less than 0.2.0.

It would not even install, would it? It would cause a file conflict,
http://fedoraproject.org/wiki/Packaging:Conflicts#Implicit_Conflicts
and turning that into an explicit Conflict is not much better.

> > 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.
> >
> It's questionable to me whether this is a rename or not. The feedback that
> Mario quotes about the packager's intention says that the packager is not
> thinking of this as a rename. It seems that currently, the datanommer
> application ships with several python modules. Some of those ae being moved
> to their own package. But the datanommer package is going to continue to exist.
> Installing the updated datanommer =will pull in the new python-datanommer-models
> package via Requires. So in practical terms, people who have the datanommer
> paackage installed will upgrade to the new datanommer and still have the
> python modules because of the Requires: python-datanommer-models in the
> updated datanommer package.

Given the speed at which this package changes, we're not talking about
weeks or months, but possibly just days that there would be a conflict
due to a rushed out python-datanommer-models package. Why can't the new
python-datanommer-models not be released _together_ with a corresponding
datanommer package?

--
Fedora release 17 (Beefy Miracle) - Linux 3.6.1-1.fc17.x86_64
loadavg: 0.36 0.28 0.25
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Rules for obsoleting or conflicting packages
 

On Mon, Oct 15, 2012 at 07:37:23PM +0200, Michael Schwendt wrote:
> Given the speed at which this package changes, we're not talking about
> weeks or months, but possibly just days that there would be a conflict
> due to a rushed out python-datanommer-models package. Why can't the new
> python-datanommer-models not be released _together_ with a corresponding
> datanommer package?
>
I think that we're anticipating that the packager is going to do different
things. When I read the quote, I'm imagining that he is going to be
releasing the new datanommer package together with the new
python-datanommer-models package. Which would mean the packagest available
in the yum updates repository shouldn't have any conflicts between the two
packages (because the Conflicts is versioned).

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Rules for obsoleting or conflicting packages
 

On Mon, 15 Oct 2012 11:18:02 -0700, Toshio Kuratomi wrote:

> On Mon, Oct 15, 2012 at 07:37:23PM +0200, Michael Schwendt wrote:
> > Given the speed at which this package changes, we're not talking about
> > weeks or months, but possibly just days that there would be a conflict
> > due to a rushed out python-datanommer-models package. Why can't the new
> > python-datanommer-models not be released _together_ with a corresponding
> > datanommer package?
> >
> I think that we're anticipating that the packager is going to do different
> things. When I read the quote, I'm imagining that he is going to be
> releasing the new datanommer package together with the new
> python-datanommer-models package. Which would mean the packagest available
> in the yum updates repository shouldn't have any conflicts between the two
> packages (because the Conflicts is versioned).

Well, it would be _so_ easy to not release the datanommer package until
the needed python-datanommer-models package will be available:
https://admin.fedoraproject.org/updates/search/datanommer

Introducing a confusing Conflicts tag (even a versioned one) can be
avoided in this case, too. It would be weird to push datanommer to stable,
if things will move/change/be replaced afterwards anyway.

--
Fedora release 17 (Beefy Miracle) - Linux 3.6.1-1.fc17.x86_64
loadavg: 0.40 0.25 0.23
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging