More explanation requested for warning about rawhide inheriting updates

[Bruno Wolff III]

On Sat, Mar 10, 2012 at 02:14:50 -0800,
  Eric Smith <eric at brouhaha.com> wrote:
> The "Join the package collection maintainers" page gives the warning:
> 
> I've never really understood that, but it's never previously caused
> me any concern.  Since I am now in a situation where I want to push
> an update to a branch (f16) without pushing any change to rawhide,
> it has me worried.  Can someone please elaborate on how this
> "inheriting" updates into rawhide works, and what can be done to
> avoid it?  I suppose the meaning is probably crystal clear to
> everyone else who has read that warning, but apparently I'm being
> dense again.

Rawhide inherits from updates of the most recent branch, which is currently
the branched release (f17). Updates will inherit from the release.
A package is only inherited if there are no builds for it at the current
level. So if a package has been built for F18, even if there is a build
with a higher version (actually it would be the latest build, not the
build with the highest version) in F17 release, that build would not
be used for rawhide.

So once you start making a build for a later release, you really want to
continue making builds for that later release.

Stuff in updates-testing doesn't get inherited into rawhide. So if there
are important fixes in updates-testing that may be sitting for a while,
you may want to consider doing builds for rawhide if you aren't already.
(Personally, I'd like to see rawhide changed to inherit from updates-testing.)

If the version used in rawhide is lower than that used in a previous
release (including its updates repo), then trying to use yum update to
go between releases gets more complicated. Currently the situation is
that you pretty much want to use yum distro-sync to update. However this
can end up removing stuff that you'll want to track so that you can
get copies later when things have been fixed. And sometimes things are
complicated enough the yum distro-sync won't be able to work either.

There is a trick to use when you want to make an update for one release
that you won't be doing in later releases and where you want to keep
the later release versions higher than the update. You can add .1 (or
.2 etc) after %{dist}.