Feature changed by: Michael Meeks (michael_meeks) Feature #308835, revision 5 Title: performance: no-ABI-change flag Buildservice: Rejected by (adrianSuSE) reject date: 2010-02-20 16:46:52 reject reason: abi change isn't the question for triggering rebuilds. Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: When submitting a package, for which we know there has been no ABI change - eg. we changed only a manual page, or where we wrote the patch ourselves and are certain - it should be possible to 'osc commit' with a flag set; such that this package will be re-built, but no dependent packages will be triggered. This is particularly key for things like glibc / hal and lower stack things, that have ABIs that ~never change incompatibly - yet lots of things depend on. Business case (Partner benefit): openSUSE.org: This would substantially accelerate repository builds, and increase the time for which they are stable. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-21 12:18:17) an abi change is not enough to avoid rebuild triggering. a header file might change anyway or the pure existins of some files can have an influence to others. you never know what other packages are using from your package. however, we have a feature to validate ABI as qa check for updates. #2: Michael Meeks (michael_meeks) (2010-01-22 14:05:33) (reply to #1) re-opening. So - lets make 'ABI' more explicit: something that has a trickle-down impact on packages depending on this one. * Many* changes, are well known not to cause such impacts at submit time - and for many lower-level packages in the stack, this triggers a vast cascade, of resource consuming, a-priori known to be un-necessary work. A trivial example is a change to a 'hal' device rule; which will trigger a re-build of the entire stack X and above. Having an explicit way to flag a commit as being "not ABI/API/side- effect relevant, would save a vast amount of time. Please re-consider. #3: Adrian Schröter (adriansuse) (2010-02-20 16:45:44) (reply to #2) What about just disabling the "Useforbuild" flag for a package or repo during doing such changes ? In that way it will not trigger other packages, but still get published. A user setting on the commit which says "will not change other packages" would imply that the user knows absolute all other packages depending on this one and know for 100% what exactly they are doing. I don't think that this can be assured by anyone at anytime. + #4: Michael Meeks (michael_meeks) (2010-02-22 14:12:17) (reply to #3) + So - yes, some other packages -may- be doing odd things, like building + a compendium of all 'man pages' containing the string 'fishy' or + something :-) I agree there is no theoretically perfect solution here. + On the other hand, there are a large number of cases where we know that + there is precisely zero point in re-building *world* - consider eg. a + single, internal NULL pointer check added to glibc, fixing a crash or + somesuch. It is ridiculous to force trigger a re-build of everything + for this. + Ultimately, my feature request is for a way for a user to help the + build-service solve such problems, that a user can see, but the build + service simply cannot. + If this twiddling of a "Useforbuild" flag works, it sounds good. I have + no idea what the flag is, how to tweak it, or indeed how to strobe it + in such a way that the 'osc commit' command turns it on/off, only until + the next submission without a "--no-ripple-effect" submission occurs :- + ) + The requirement is ultimately, to have a parameter addable to 'osc + commit' and 'osc submitreq' that propagates this human understanding + that there is no need to re-build. + Naturally, I don't propose to use this optimisation for full product + builds, just during development. -- openSUSE Feature: https://features.opensuse.org/308835