On Wednesday, 06 May 2009, at 20:23:51 (-0400),
Jeff Johnson wrote:

> 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.

Sort of.  I'm not entirely of the opinion that there is a "problem,"
per se, in the current mechanism.  It's really a question of policy:
whether or not an obsoleted package, once transactionally removed,
should be allowed to reappear.

With the current situation, the distro packagers can choose which
policy they want.  If they choose not to forceably prevent the package
from being installed, they don't need the Conflicts.  Otherwise, they
do.

I like this for two reasons:  (1) Works as is with no additional code,
and (2) provides choice.

> 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.

Unversioned Obsoletes are a known "evil" that I've been preaching
against for years, but I don't have a very large congregation. ;-)

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

True.  But the failure would most likely occur during an explicit
install request for that package (as opposed to a general "update" or
"upgrade" operation)...unless of course the distro packagers
completely screwed the pooch and had a requirement actually trying to
pull the package they themselves obsoleted back in....

> 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.

True.

> 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!

Only if they look at it as a mechanism rather than a policy decision.

Besides, 2 of the 3 are already necessary.  What's 50% more?  ;-)

> 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.

bug#233713 makes me cry too.

> 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.

I think I'd feel more comfortable with permanent Obsoletes if done as
stated above (invisibility scares me), perhaps also with the added
provision that unversioned Obsoletes not be allowed to persist.

Someday we should discuss the possibility of forcing unversioned
Obsoletes to act exactly like Obsoletes: <= V-R

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

I was trying to save you work!  :-)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@kainx.org>
Linux Server/Cluster Admin, LBL.gov       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "The future is all around us, waiting in moments of transition to be
  born in moments of revelation."                  -- G'Kar, Babylon 5