[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