[Starlingx-discuss] Trying a "mirrorless" build
Scott Little
scott.little at windriver.com
Mon Jul 30 14:40:23 UTC 2018
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 at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
More information about the Starlingx-discuss
mailing list