Selective upgrading of packages

Posted Jul 16, 2012 17:26 UTC (Mon) by dwmw2 (subscriber, #2063)
In reply to: Selective upgrading of packages by epa
Parent article: Left by Rawhide

You can use yum to upgrade specific binary packages from Rawhide. For example yum --releasever=rawhide update openconnect should pull in the specific package and any of its dependencies. And if its list of dependencies comprises the whole world including glibc, you get to say 'no' and rebuild from source instead.

Note that this doesn't always work. Some GNOME projects are deliberately shipping with broken dependencies so the Rawhide packages aren't marked as requiring new libraries even though they do.

to post comments

Selective upgrading of packages

Posted Jul 17, 2012 13:05 UTC (Tue) by Yenya (subscriber, #52846) [Link] (2 responses)

There is another problem in rawhide: it is not even usable for "let's see whether the latest-greatest version of this package fixes my problem": after reproducing my problem with rawhide packages and reporting the bug, I have been told "it is already fixed in Koji". And indeed, there has been several days old package in Koji, which contained the fix.

So as a side note, the whole mirroring of gigabytes of rawhide is pretty useless even for testing, because rawhide, from the tester's point of view, is already outdated.

Selective upgrading of packages

Posted Jul 17, 2012 20:54 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

If you're serious about reporting bugs (not just running the latest and greatest) you should point yum directly to koji repos. That way you can test packages without he rawhide lag

Though the infra price should be paid in useful bug reports

Selective upgrading of packages

Posted Jul 18, 2012 6:21 UTC (Wed) by michich (guest, #17902) [Link]

It's unusual that a several days old build was in Koji without reaching Rawhide. I thought Rawhide gets updated with the latest Koji builds every day.

By your reasoning you'd have to conclude that testing of anything is always useless, because the developer could respond with "I already fixed the bug in my local git tree" or "I already thought about this bug and have a fix planned in my head". The fix propagation delay can simply never reach zero.