[idea] monitor a few packages 'closer' for rebuild triggers required

[DimStar77]

Reference: https://bugzilla.opensuse.org/show_bug.cgi?id=995367

openSUSE:Factory is (usually) built using rebuild=local, meaning only the packages with source changes are being built (which helps us making daily snapshots posisble)

There are a couple packages that should be handled in a different mode: be retriggered if their deps changed / rebuilt

A typical example here is installation-images:{openSUSE,Kubic}: whenever yast for example changes, this package requires a rebuild, to get the latest installer actually to be used during installation.

I likely need some way to query obs for a specific package has been built with the CURRENT packages of it's dep chain, or if there are differences.

so something along the line

diff -u <(osc api build/openSUSE:Factory/standard/x86_64/installation-images:openSUSE/_buildenv) <(osc buildinfo openSUSE:Factory installation-images:openSUSE standard x86_64)

note: this does not work, as OBS does give different info in buildenv vs buildinfo... one has version=/release= and the other has hdrmd5= attributes

-  <bdep name="yast2-x11" hdrmd5="56f7d2fd56fb83e71a8473b8aa4bcb57" project="openSUSE:Factory" repository="standard" />
+  <bdep name="yast2-x11" version="3.1.5" release="1.4" arch="x86_64" project="openSUSE:Factory" repository="standard" />

[DimStar77]

@adrianschroeter - you might have good ideas for an implementation here; there is a good chance the backend offers all we need already

[adrianschroeter]

erm, no, the only way in this situation is to cause a source change. eg. via linking them and changing a file (which may not be used during building).

Given that you scheduling happens entirely outside of OBS we can't help much here. Maybe it would be good to implement the scheduling inside of OBS with another strategy?

In theory there could be some marker for package containers which overrides the strategy there, but this is not implemented.

[DimStar77]

if we can get the logic inside OBS and have a strategy be 'overruled' by a package, that would be certainly the best way of course.

we are currently combatting two 'issues' with the rebuild=local strategy (which is generally seen working fine)

• installation-images are not being triggered (which I tried by inspecting the various buildinfo available, but, as said, they don't provide the same data; installation-images should retrigger when it's 'parents' change
• ghc* is a pain - currently I just retrigger 'every now and then' the entire dep tree starting at ghc (osc whatdependosn ghc); it would be great if ghc* package could be marked as 'needing direct strategy for their children)

the installation-images case is 'higher prio' for me, the ghc case I learnt to live with (and have a rebul-dep-chain) that handles this semi-automatic for me)

[dirkmueller]

I guess rebuild per package override would be the simplest solution indeed, so some packages could be set to a rebuild=(in)direct strategy.

Overall it would be really nice to have the current manual-rebuild mode implemented in OBS natively, but that's probably another ticket.

[coolo]

How relevant is this now? I don't think an OBS scheduler change is any more likely in the next 4 years than it was in the last 4 years - so how can we improve client side?

[DimStar77]

We have 'something' in place for the 'very bad candidates'

from OSRT:Config:

# packages in here are rebuild if their buildinfo changed
rebuildpacs-leafs = branding-openSUSE PackageKit-branding-openSUSE xfce4-branding-openSUSE xfce4-branding-openSUSE installation-images:openSUSE installation-images:Kubic installation-images:MicroOS installation-images-extras rpmlint rpmlint-mini yast2-schema perf

So, the OBS internal improvement of scheduling is a nice to have, but will likely remain a dream.

rebuildpacs-leafs at least allows me to list packages that must be retriggered more often

[coolo]

So can we close this as dream?

[DimStar77]

realistically seen, yes