Tracker?

[Paul Howarth]

seth vidal wrote:
> On Mon, 2006-11-13 at 13:28 +0000, Paul Howarth wrote:
>> seth vidal wrote:
>>> On Mon, 2006-11-13 at 09:58 +0100, Ralf Ertzinger wrote:
>>>> Hi.
>>>>
>>>> On Mon, 13 Nov 2006 00:44:16 -0500, seth vidal wrote:
>>>>
>>>>> If the old one is still there then it still obsoletes tracker.
>>>> So if I have packages A and B, where B obsoletes A. Now there is a rpm-newer
>>>> version of B (B-new) in another repo (updates) which no longer obsoletes A.
>>>>
>>>> So as long as B exists anywhere I can not install A using yum, because
>>>> yum still considers the obsolete from B, even though it is no longer relevant
>>>> in any way?
>>> When I was working on the obs vs updates code I kept asking about this.
>>> The answer I repeatedly got was that obsoletes trumps updates no matter
>>> what.
>> Was there a reason given for this? What breaks if it's the other way around?
> 
> mainly that an obsoleted package should stay obsoleted.

However, that means that if somebody carelessly uses an unversioned 
obsolete in a package that goes into a distribution release (i.e. the 
core repo), it is impossible to fix that error by issuing an update that 
removes the obsolete.

Take for instance the selinux-policy package in FC5. The version in the 
core repo obsoletes selinux-policy-devel, which was fair enough at the 
time of the release as there was no separate selinux-policy-devel 
package in Fedora. However, during FC5's lifetime, it became apparent 
that having an selinux-policy-devel package was desirable from the point 
of view of managing dependencies, and so the selinux-policy package was 
split into selinux-policy and selinux-policy-devel. This worked just 
fine on FC5 and is working fine on FC6 too, where there has been an 
selinux-policy-devel package in the core repo.

Where there is a problem is in building packages targeting FC5 using 
mock on FC6. The version of yum in FC6 behaves differently to the 
version in FC5, and decides that a buildreq of selinux-policy-devel 
(which should be picked up from the updates repo) is obsoleted by the 
selinux-policy package in the core repo and can be replaced by it. 
However, that package is buggy and cannot in fact be used to build 
things. So it's not possible to build packages requiring a buildreq of 
selinux-policy-devel for FC5 targets on an FC6 host without excluding 
selinux-policy from the core repo.

Coming back to the "an obsoleted package should stay obsoleted" theme, 
couldn't it be argued that version n of a package is obsoleted by 
version n+1 of the same package, and hence version n of a package should 
be ignored in the presence of version n+1?

Paul.