On Wed, 09 Jun 2010 18:00:15 -0400, James wrote:
On Wed, 2010-06-09 at 21:38 +0200, Michael Schwendt wrote:
> On Wed, 09 Jun 2010 14:39:52 -0400, James wrote:
> > And if the user never has pkgA-1 installed, and does "install
> > pkgA-blah" then that's all they'll get.
>
> If you modify the scenario, we will talk past eachother.
> The scenario is:
I didn't.
http://poelcat.wordpress.com/2010/04/28/monty-python-does-the-fedora-deve...
> 1. User has pkgA-1 installed.
Ok, so, as I said before...
1. User has nothing installed.
We can stop here already. Let's meet somewhere in the middle. Your case is
_another_ valid scenario, but it disregards the simple fact that the
package split leads to an install operation erasing an already installed
package and thus crippling/damaging the installation depending on what
gets removed. As it _may be_ possible in some cases to fix the package
dependencies and avoid such a scenario, I just say that playing with
Obsoletes bears risks.
Now you might argue that there are packages, for _both_ our
examples,
where the user really does want pkgA as well (and it's not a strict
requirement).
We may get suggests eventually, but this has nothing to do with
Obsoletes.
In general, only the "Obsoletes" lead to erasing an installed package,
which is the dangerous part about introducing too many Obsoletes in
packages or sub-packages. [We've escaped from the times when Provides
also replaced packages.]
> That isn't what I refer to. For some splits you don't
have a requirement.
> See e.g. a real-world example, where installing/adding a Nagios plugin
> package removed Nagios because of competing Obsoletes:
>
https://bugzilla.redhat.com/590709#c13
This example is a little more convoluted, esp. as F-12 doesn't have
-common before and -common always had it (and should thus. have used a
"Conflicts: nagios < 3.2.1-2" in nagios-common).
That ticket is just one example of "Obsoletes" having lead to packaging
bugs. First, a package split lead to erasing an installed package during a
normal _update_ scenario. Then followed attempts at fixing up the
packages with competing Obsoletes for a specific _install_ scenario,
which also didn't work out, because of missing strict dependencies due to
how the split is done.