On May 7, 2009, at 3:22 AM, Michael Jennings wrote:

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

The problem is that Obsoletes: is not meeting expectations.

So either the expectations or Obsoletes: can be changed.

Since expectations of RPM are way out of line with reality for
many years, I'm focusing on the solvable engineering issue of
making Obsoletes: persistent.

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

Heaven forbids "choice", not me. Meanwhile, coding usually involves
choosing what to implement and how.

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

I will sing in you choir anytime. But "evil" is just more "RPM sux!"
heresy. I consider non-persistent Obsoletes: a minor sin, like
lusting after apt or yum, that a couple of hosannahs and rosary
bead fetish counting might fix to ensure perly gate entry, nothing more.

>> But the problem remains that Conflicts:, unlike Obsoletes: is a
>> full-stop failure as usually implemented by RPM depsolvers.
>
>
> 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?  ;-)
>

... technically the Provides: is optional too, not all Obsoletes:
are replacements.

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

Shrug. It just isn't that hard to fish an integer tagno out
of configuration. Lusers luse, life goes on.

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

Permamnent Obsoletes: will come with
	rpm -q --whatobsoletes foo
which is hardly invisible.

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

The issue will be where "V-R" comes from. Comparisons on "invisible"
versions just cannot be attempted.

>> Us lazy schmucks love the zero-effort, already implemented, been
>> there, done that, solutions. ;-)
>
> I was trying to save you work!  :-)
>

Hehe ... actually the work has already been done, I'm just coasting to
5.2.0 release. Note that coasting to the 5.1.8 release got me
whiling away my time with embedded interpreters out of boredom.

And I do want to get back to multi-threading, sigh ...

73 de Jeff