On Wed, May 6, 2009 at 7:43 PM, Jeff Johnson <n3npq@mac.com> wrote:
> (aside)
> I ask this question (and other questions like whether SRPM
> installs should be tracked) periodically, have for years.
> This bug report triggers the duty/obligation to ask Yet Again:
>
>     https://bugzilla.redhat.com/show_bug.cgi?id=499239
>
> Obsoletes: are applied once, when the package that carries
> the Obsoletes: is upgraded.
>
> Basically that leaves a back-door where a later install/upgrade
> of the Obsolete:'d package(s) is permitted. The issue is periodically
> re-discovered and invariably leads to
>        RPM sux!
> conclusions.
>
> The proper "fix" is to make Obsoletes: persistent like Conflicts:,
> with a semantic that any Obsolete:'d package added to a transaction
> is automagically discarded (with or without warning with all the usual
> enablers/disablers for the warm/fuzzy bikeshed discusssions).
>
> Should I make Obsoletes: in RPM persistent?

In my (very humble) opinion the clause Obsoletes must have a
well-defined semantics comparable to Conflicts ( or as Requires or
Provides ) : historically they are together referred to as the four
dependencies that the RPM system tracks and, if there are not special
reasons, should have a equivalent semantic on persistence. . So my
answer is yes.

It would also be interesting for me to understand the details of such
development.

Regards