On May 6, 2009, at 6:14 PM, Michael Jennings wrote:

> On Wednesday, 06 May 2009, at 18:05:23 (-0400),
> Jeff Johnson wrote:
>
>> So how do I solve this problem? For better or worse, packages do get
>> renamed, and its common packaging practice to add an Obsoletes: when
>> doing so. It just doesn't work like expected.
>
> Seems to me that the logical course of action, should permanence be
> desired, would be to add Conflicts: old-name <= %{version}-%{release}
>

OK.

So your way to solve the problem is to recommend adding
	Conflicts: oldname <= someversion
as well as (for legacy compatibility)
	Provides: oldname <= someversion
as well as (for automation and depsolver discovery hint)
	Obsoletes: oldname <= someversion
whenever a package is renamed.

Aside from the fact that "someversion" is often not precisely known, and
that what is often done when the precise "someversion" is unknown is a
sloppy and incoherent DWIM dependency assertion expression
	Obsoletes: oldname
which overlaps (against expectations), and ignoring the fact that all of
above often has to be added to multiple packages, often with retrofit  
rebuilds
of already released packages (which never happens everywhere), you
are quite correct that persistence can be achieved with means already
supplied by RPM without making Obsoletes: persistent.

But the problem remains that Conflicts:, unlike Obsoletes: is a
full-stop failure as usually implemented by RPM depsolvers.

(aside)
Yes apt and smart and perhaps zypp these days will uninstall packages
to solve Conflicts: dependency assertion failures.

And a luser, when faced with the frustrations of repeated upgrade  
failures,
will still arrive at the same end-point
	RPM sux!
because of the simultaneous problems of high expectations, short  
attention
span, and the low rewards of being a Fedorable rawhide QA laboratory  
rat.

As will the package monkey, who will wonder why 3, not 1, assertions
	Provides: oldname <= someversion
	Conflicts: oldname <= someversion
	Obsoletes: oldname <= someversion
are required to do even a simple obvious task, like renaming a  
package, will
also come to the conclusion
	RPM sux!

And an RPM developer, when asked repeatedly for final calls on
how to solve packaging problems that are quite logically simple
will eventually do anything necessary to solve the problem,
including using RPMTAG_NAME rather than RPMTAG_PROVIDENAME to
test dependency assertions, thereby reverting widely deployed
software in an incompatible and Baroque'n fashion making matters worse.

But you want Conflicts: behavior instead. Note that it really
isn't hard to save Obsoletes: persistently, but instead of
an automagic filtering of added packages, have rpm behave exactly
as if
	Conflicts: oldname <= someversion
had been typed by the package monkey in the spec file, and
incorporate configuration to match the assertions against
RPMTAG_NAME, not RPMTAG_PROVIDENAME, for Baroque'n changes
from an RPM maintainer, and the luser can be instructed to
	Use smart!
so that that Conflicts: are used as depsolver hint to uninstall
some instance of the oldpackage that has managed to become
installed all over again again again.

Us lazy schmucks love the zero-effort, already implemented, been there,
done that, solutions. ;-)

> That way the other package can't be installed while the new one is.
>
>> (other quite cogent arguments snipped but not ignored)
>
> :-)

There are valid points in the snipped parts, basically that
something more general and simpler, needs to be achieved.

73 de Jeff