OK,
The problem is that "obsoletes" can mean two things:
1) If you install me, you must remove him.
2) If you have him installed, you must remove him and install
me instead.
The two interpretations respectively fit nicely, I think, with the
two actions "update/install" and "upgrade".
Currently, "install" and "update" both ignore obsoletes completely,
while "upgrade" looks at all obsoletes in all available packages,
whether they are installed or not. I think this violates the
principal of least astonishment. (When a choice of actions exist,
that action is best that astonishes least.)
If I have requested package A be installed on my system (no matter
how indirectly) and A depends on a package B, then B should be
installed as well. This is what yum currently does.
By analogy, if I have requested package A be installed on my
system, and A obsoletes B, then I would expect B to be removed.
Currently, there is no way to tell yum to do this without invoking
upgrade, and all that implies.
Now, if A depends on B and B obsoletes A (however indirectly) then
there is simply a bug in the repository, and it should be fixed.
Yum-arch should detect such problems and refuse to build the
databases.
On the other hand, there is *not* a problem if A obsoletes B and B
obsoletes A (however indirectly) -- this is just an indication that
no more than one of either A or B should be installed at one time.
In this case, the user must choose between A and B, and yum should
not override the user's choice.
So.... that said: Does this solve the problem?
yum update :
looks at the obsoletes clauses of only the new rpm's it decides to
install because they correspond to things already installed (or
will be installed because of dependencies of things that correspond
to things that are already installed (and so on...)). This
corresponds to interpretation (1) above.
yum upgrade :
looks at the obsoletes clauses of all candidates for installation,
whether they are already installed or not. In case of an obsoletes
loop, preference is given to packages that are already installed.
If there are no loops, and A is installed, and B is not installed,
but B obsoletes A, then A will be removed and B will be installed.
This corresponds to interpretation (2) above.
yum install :
looks at the obsoletes clauses of those packages it decides to
install (including those that are included because of dependencies)
and acts upon them. This corresponds to interpretation (1).
In all cases, the user is told of what will happen, and asked for
permission to proceed -- just like now.
Clearly, there needs to be a way for saying "I know there may be
loops. But I want to have exactly 'this' happen -- just do it."
We may not need new syntax to accomplish this. A carefully
thought-out sequence of "install", "remove", and "update" actions
targeting particular packages should be able to accomplish anything
we need to do along these lines.
I believe this is a reasonable (read "minimally astonishing")
interpretation of what the man page says regarding the differences
between "update", "upgrade", and "install".
This disambiguates (without violating the principal of least
astonishment) all "simple" loops (A obsoletes B, B obsoletes A). I
don't know about more complex loops, though... Can anybody think
of a case where it results in "astonishing" actions?
Rick
On Wednesday, August 6, 2003, at 11:54 PM, Axel Thimm wrote:
> On Wed, Aug 06, 2003 at 11:29:38PM -0400, seth vidal wrote:
>>
>>> The problem is that those two packages are breaking integrity of
>>> rpm repos, be it yum, apt or rpm -Fhv *.rpm. It is too bad this
>>> slipped through in older RH.
>>>
>>> What is yum's behaviour ("upgrade") in this case? Would it toggle the
>>> packages at each yum upgrade? Can such obsolete-loops be detected and
>>> the installed package preferred?
>>>
>>> I know apt cannot :(
>>> But yum could be smarter! :)
>>
>> no, actually yum can't be smart - it would have to be a policy
>> statement
>> of 'if foo obsoletes bar and bar obsoletes foo, then foo always wins'
>
> The policy I outlined above is to prefer whichever package is already
> installed.
>
> Maybe yum could remove obsoleted packages in its upgrade computation?
> That way if neither foo nor bar are installed, they won't get in with
> a yum upgrade, and if on is installed, it will not start toggling.
> --
> Axel.Thimm@xxxxxxxxxxxxxxxxxxx
> _______________________________________________
> Yum mailing list
> Yum@xxxxxxxxxxxxxxxxxxxx
> https://lists.dulug.duke.edu/mailman/listinfo/yum
