FC-4 Extras buildsystem breakage details

[Jeff Spaleta]

On 2/22/06, Patrice Dumas <pertusus at free.fr> wrote:
> Sorry... It shows once more that providing an old code instead of using
> the system one is bad.

Without getting into the specifics as to when you should be encouraged
to use private codebases in packages. When it's done  you have to be a
bit careful to make sure you aren't exposing that codebase as a
provides. This can involve disabling rpm's normal automatic provides
detection  and hide the private modules from rpm's automatic perl
module detection.

The questions I'm most interested in now involve preventing things
like this from happening in the future.  Would reviewing the provides
from a mock build a hard requirement for pre-submission status have
helped prevent this?  I could see an argument for checking to make
sure that a new extras package does not provide duplicate provides as
packages in the standard build environment. And if they do, we make
sure its not a problem before they get into the tree.  Or can this
sort of test be scripted in the buildsystem and flag a package build
if it disturbs the normal build group?  In a sense would it make sense
to make the build environment "immutable" and require special action
to build packages (new or updates) that would change the list of
packages in the build environment being used in the buildsystem?

-jef