Reduce mixer build bundle scope to changed bundles

[gtkramer]

If a build only has one package changing that is found in only a small handful of bundles, do all of the bundles need built? Given mixer produces a stateful workspace that is iterative, would it be possible to build bundles only for the bundles that have changed to coincide with how the update is performed? I think existing information to populate Manifest.full should be able to be obtained from existing manifests if I understand how changes work across manifests correctly.

[rchiossi]

The problem right now is that the process of building the bundles is what we use to figure out what changed, but in theory it should be possible with a change in mixer architecture.

[gtkramer]

Ah, that makes sense. That's where the manifest info and includes files are made. I think that's still reasonable to do, and probably unavoidable, but maybe we don't need to install all bundles? Combined with doing the rpm2cpio bits, I think doing less work in parallel would be a big speed up.

[gtkramer]

I'm not sure how this plays into a possible long-term strategy, but if we want to start farming out work with mixer onto multiple machines, I think it would be useful to have the process/logic already in place to only build the bundles that have changed (and subsequently the update off those bundles).

[insilications]

Yes, a simple bundle with a few dozen file changes takes more than one hour in a 9900ks in my personal mix update. It would be nice to have the control to customize CL without having to wait more than one hour to update. It is unsustainable for small developers.