Juergen Weigert wrote:
On Jul 17, 12 11:37:57 -0300, Claudio Freire wrote:
If a package builds differently in different environments, it's bad for stability to actually build it in different environments. You want to be sure you'll build it the same way each time, so you know you're not introducing bugs by simply rebuilding.
For asserting a particular environment, we need to do two thing: a) make sure everything is there that should be there. b) make sure nothing is there that should not.
BuildConflicts appears to be the tool to keep packages out. While BuildRequires is quite practical for a), BuildConflicts appears to be not so helpful for b). It would require a patient maintainer to find all possible conflicts.
Certainly, most people would consider it a bug if the package rpms you were building, were installed after the build, and the build was repeated -- and then failed. Having such radically different results based on the presence of the package contents you are building is almost fits the definition of entrapment -- "i.e. you can build it, but if you install it -- (a logical thing to do once one has built it), then you can no longer build it. *Even if* the idea of building in the presence of a complete, ***CLEAN*** development install, is an _anathema_ to normal build procedures (which is a questionable premise for "distro" organizations), it should at least be part of testing -- i.e. can the distro just built, be installed, with full devel packages, and build the distro it just built (and can that pass the test suites -- including 1 more build) -- WITH NO REQUIREMENT of binary equality of the code produced (that would be all but a guaranteed fail!). Just a test -- can the distro build itself when it is fully installed? and does that result pass all tests. I've been in both compiler groups and product verification groups and a 1st level rebuild was not at all abnormal for compilers and similar tools. And binary comparisons between gens 2 & 3 were required (with tools to ignore date-driven fields)-- as the code produced between gens 2 & 3 should have been identical (and was, or it didn't pass testing). At that point, you know you have a complete package with source and tools that can generate itself reliably. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org