In case any of the source files changed, openSUSE Build Service rebuilds the dependent packages regardless of whether that particular modification affects the dependency. This makes our resources footprint bigger (and the electrical power bills higher). It also affects users, because every new package build causes the package manager to include that package in the next update thus consuming network bandwidth and resources of users' computers.

Current OBS controls for package rebuild triggers

It is possible to control dependent packages build triggers on a per repository basis (see OBS build scheduling strategies). You will find an explanation on that page that any setting other than the default, which is "always rebuild", is not safe and should not be used if the packages are to be distributed. Apparently, the concern is more of a "this repository is official/testing" kind.

Which modifications justify rebuilding

First, we need to define the modifications which justify rebuilding the dependencies. This is a list which should be amended by the more knowledgeable on software builds:

  • new library versions or binary API changes (the latter should always cause the former?)

  • changes in #includes files (in case of library development packages); it is preferable to verify if the dependencies can build with these modifications sooner rather than later

Possible improvements

Extend the checkin command

I suppose that this is a hard problem to solve automatically, so it is good to start small with some infrastructure to allow managing the dependencies rebuild process. We could add the "don't rebuild/must rebuild dependencies" option to the checkin command.

Make builds reproducible

There are ongoing efforts to get reproducible builds, that is if the source has not changed, then the built package should be exactly equal to the previous build too.

According to osc triggerreason on several packages in the openSUSE Build Service reference instance, quite a few rebuilds were due to md5 sum not matching. If more builds were reproducible that would obviously reduce the total number of builds. More, a reproducible build would (almost) completely remove transitive builds (see the build project attribute).

See the following pages for more information:

Questions

  • Is there a facility in OBS similar to the Debian's dh_buildinfo? Would that be useful in OBS? Is there a way to keep that information within the existing infrastructure?

  • How are md5 sums produced?

Resources

  • osc triggerreason --help

  • osc jobhistory --help

Looking for mad skills in:

obs perl buildservice parsing

This project is part of:

Hack Week 10 Hack Week 11

Activity

  • over 2 years ago: aspiers liked Reduce the number of builds in the openSUSE Build Service
  • almost 4 years ago: im_unbob liked Reduce the number of builds in the openSUSE Build Service
  • almost 4 years ago: dmuhamedagic added keyword "parsing" to Reduce the number of builds in the openSUSE Build Service
  • almost 4 years ago: dmuhamedagic added keyword "buildservice" to Reduce the number of builds in the openSUSE Build Service
  • almost 4 years ago: dmuhamedagic added keyword "obs" to Reduce the number of builds in the openSUSE Build Service
  • Show History

    Comments

    Similar Projects

    openQA Package Testing by RBrownSUSE

    openQA has a well earned reputation as a 'full ...


    Bootstrap openSUSE for MIPS by a_faerber

    While in the past MIPS boards were either low-e...


    "emerge" for rpm/SUSE by dmacvicar

    There are lot of packages that can't be hosted ...


    bugzilla nick completion privacy extension by AndreasStieger

    Bugzilla supports [automatic username completio...


    Dochazka by smithfarm

    Dochazka is a long-term project to replace the ...