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.
I'm reading that this is okay usage into this section:
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
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,
and turning that into an explicit Conflict is not much better.
> There's also the "Package Renaming Process".
> 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
> "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
Fedora release 17 (Beefy Miracle) - Linux 3.6.1-1.fc17.x86_64
loadavg: 0.36 0.28 0.25