On 2/18/06, Dan Williams <dcbw@xxxxxxxxxx> wrote: > Whee, more layers of complexity. A mandatory pre-publish testing pretty much demands the complications, in a way that a scratch area does not. But even a scratch area will need to be integrated into the buildsystem for maximum benefit. Anyone wanting to test that a set of packages that make up a dependancy chain work.. will need to turn on the scratch area to fill deps as they walk through the chain. Example: if a new update to application bar needs an update to package libfoo and the current release of application bar wont work with the new libfoo. As a maintainer you'd like to use a scratch build on the buildsystem to make sure the new set of foo and bar both build as expected so you can push both packages to the release tree so noone experiences am unrecoverable dep problem if they are not pushed together. Testing the new libfoo by itself isnt useful because if you push it but the new application bar doesn't build.. you have broken the deps for the old version of bar. And you can't scratch test the new version of bar with the released version of libfoo. You'd have to scratch test the set or you don't get value from the scratch. -jef -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
