I think there is a fundamental tension between between two views of were StarlingX should go. Vision A, StarlingX's is about a usable iso) + If software context X (tag, branch what ever) compiles today, it should compile tomorrow. + Software context X (tag, branch what ever) should always produce the same iso when compiled. - Requires that the set of packages that we compile against be frozen in some fashion. Vision B, StarlingX is just software) + Always use the latest and greatest packages. I don't want to hand manage which external packages are used. - Builds may break at any time due to external factors, even on release branches. Folks who want to make a functioning product likely prefer A. Folks that want to work with the latest features, or prototyping new features might prefer B. You experiment is solidly in the B camp. I did experiment with yum priorities recently, but it didn't deliver the desired result. An older StarlingX package with higher priority failed to override a newer upstream package. Instead yum threw an error because newest package was ... 'eclipsed'... I think the word was. Couldn't find a quick way to suppress that error, so I abandoned the experiment. Scott On 18-07-27 07:02 PM, Cordoba Malibran, Erich wrote:
Hi all,
I tried an experiment on building StarlingX without downloading a mirror and use mock/yum to download and resolve depenencies on the fly.
I want to share with you this report[0] with the findings.
I hope you can find this interesting :)
-Erich
[0] https://gist.github.com/ericho/049d1908f5d80485541e918515996702 _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss