How does one deal with obsoleted updates from updates-testing

[James Antill]

On Mon, 2010-03-08 at 18:54 +0000, Quentin Armitage wrote:
> On Mon, 2010-03-08 at 10:26 -0500, Seth Vidal wrote:
> > 
> > On Mon, 8 Mar 2010, Quentin Armitage wrote:
> > 
> > > The glibc packages (including nscd) were in updates-testing, but have
> > > been obsoleted, and so 2.11.90-12 is now the current version again. What
> > > is the mechanism for becoming aware that a package that has been
> > > installed through updates-testing has been obsoleted (especially since
> > > the standard install of F-13 rc has updates-testing enabled)?
> > 
> > They've not been obsoleted, they've just been updated. Obsoleted has a 
> > different special meaning in rpm-parlance.
> > 
> Sorry, I should have been clearer. glibc-2.11.90.14 is showing in Bodhi
> as being Status: obsolete. Bodhi shows that version was pushed to
> testing, and it was installed on my system when I installed F-13 on 1st
> March. That version appears is now no longer in updates-testing, and the
> current version is the earlier version, glibc-2.11.90-12. So far as I
> can see, there is no automatic mechanism to become aware of when a
> package has been in updates-testing and has subsequently been removed
> (?due to obsoleting in Bodhi), and the package needs reverting to an
> earlier version.

 I assume you know about yum downgrade, and yum list extras (and/or
using the color indications in yum list) with updates-testing enabled.

 So I assume you want something else, I guess a push kind of
notification?
 If you've commented to the update doesn't bodhi email you if the update
is removed? If not I'd say create a bodhi RFE ... but apart from that
I'm not sure how a push notification could occur.

-- 
James Antill - james at fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching