On 2/22/06, Patrice Dumas <pertusus@xxxxxxx> 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
