hal + pam update errors

[seth vidal]

On Thu, 2007-04-05 at 14:02 -0400, Will Woods wrote:
> On Thu, 2007-04-05 at 13:59 -0400, Will Woods wrote:
> 
> > Maybe we need a similar workaround in multilib repositories until we
> > have a proper solution in RPM? A static list of packages that are no
> > longer multilib, and (optionally) the library packages that replace
> > them?
> 
> For the record - as I understand it, this problem only comes up when a
> package gets un-multilibbed, and we have code in anaconda to handle this
> for proper system upgrades. So it only affects people testing rawhide or
> doing (unsupported!) yum upgrades between releases. So the actual
> severity is fairly low.

except when they go from fc6 to f7 and it stops being multilib for them.
Then they'll get it.

The issue is that there is no way for yum to know to dump this other
package. That's the principle of what obsoletes are supposed to do.
Unfortunately obsoletes don't know anything about archs so we can't say:
hal.x86_64 obsoletes hal.i386 and dispense with it. and we can only
obsolete on packagename so there's no way to do:
 hal.x86_64 obsoletes something-that-hal-i386-only-provides

You could do a whitelist/blacklist/removelist but it's going to be a
crapshoot at best.

For another problem of orphaned/dead packages we discussed an additional
metadata type for dead-packages that should be removed from folks'
systems if they're found. That might be the only workable solution. We
could get arch and evr specific with that if implemented sanely.

ThoughtS?
-sv