Bug 688857

This is the intended behavior, at least with regard to dependencies.  The idea is that features can contain "holes" that get filled in appropriately given their context.

Say feature F is installed on group G.  F depends on F', and foo.redhat.com is a member of explicit groups G', G, and G'', from lowest to highest priority.

In this case the F' dependency can be satisfied on a given node in several places:  in the group that installs F (G), in a group of lower priority (G'), in a group of higher priority (G''), in the default group, or in the identity group for F.  By a priori forcing dependencies to be satisfied in a particular order, we would lose this flexibility.

Note that inclusions, as opposed to dependencies, are ordered and thus have explicit priority:  applying a feature repeatedly applies its included features to an empty configuration, in inverse priority order, followed by the parameters set immediately in the top-level feature.  (This is recursive, so as to account for transitive inclusion.)  As an example, if F0 includes F1 and F2, its configuration will consist of:

  1.  the parameter-value mappings set immediately in F0 applied on top of
  2.  the configuration of F2 applied on top of
  3.  the configuration of F1

Where "the configuration of X" is defined recursively as its immediately-set parameter-value mappings applied atop the configurations of its included features.