[New: openFATE 314335] Continue packaging where it failed
Feature added by: Sven Burmeister (rabauke) Feature #314335, revision 1 Title: Continue packaging where it failed Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Sven Burmeister (rabauke) Partner organization: openSUSE.org Description: Simple use case: A user compiles a new version of some big app, e.g. an office suite. This will take hours of obs resources. Now the new version includes some new files or lacks some which are part of the spec file. The packaging will fail and after the user has changed the spec, the whole package is re-compiled although this would not be necessary. In fact, since the user changes some part of the spec file, he will get an instant rebuild on obs, due to the current scheduling algorithm. There are other possible, comparable packaging failures as well. So the question is how this can be handled in a smarter way, i.e. how to avoid re-compiling the whole source if it is not necessary. This involves balacing resource wasting due to keeping a failed build alive and wasting resources because of having to recompile everything. -- openSUSE Feature: https://features.opensuse.org/314335
Feature changed by: Sven Burmeister (rabauke) Feature #314335, revision 2 Title: Continue packaging where it failed Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Sven Burmeister (rabauke) Partner organization: openSUSE.org Description: - Simple use case: A user compiles a new version of some big app, e.g. an - office suite. This will take hours of obs resources. Now the new - version includes some new files or lacks some which are part of the - spec file. The packaging will fail and after the user has changed the - spec, the whole package is re-compiled although this would not be - necessary. In fact, since the user changes some part of the spec file, - he will get an instant rebuild on obs, due to the current scheduling - algorithm. There are other possible, comparable packaging failures as - well. So the question is how this can be handled in a smarter way, i.e. - how to avoid re-compiling the whole source if it is not necessary. - This involves balacing resource wasting due to keeping a failed build - alive and wasting resources because of having to recompile everything. + Simple use case: + A user compiles a new version of some big app, e.g. an office suite. + This will take hours of obs resources. Now the new version includes + some new files or lacks some which are part of the spec file. The + packaging will fail and after the user has changed the spec, the whole + package is re-compiled although this would not be necessary. In fact, + since the user changes some part of the spec file, he will get an + instant rebuild on obs, due to the current scheduling algorithm. There + are other possible, comparable packaging failures as well. + So the question is how this can be handled in a smarter way, i.e. how + to avoid re-compiling the whole source if it is not necessary. + This involves balacing resource wasting due to keeping a failed "build" + alive (i.e. something which failed in the "%install" section) and + wasting resources because of having to recompile everything. -- openSUSE Feature: https://features.opensuse.org/314335
participants (1)
-
fate_noreply@suse.de