[Starlingx-discuss] Trying a "mirrorless" build

[Jones, Bruce E]

Chris wrote: 
> I think Scott's point about A is not so much about keeping the same set of packages forever, but rather that if I build a given release today and then build that same release a month (or a year) from now it should result in the same package versions in the ISO.

I agree that repeatable release builds should be the goal.  That's why we branch, of course.   I don't think we need (or want) to get to completely repeatable releases (e.g. at the toolchain level) but just at the package level.  

For package dependencies,  I know of three ways to handle them - 1) create a big mirror that includes the union of everything 2) version the mirror in parallel with the release branches 3) let koji handle dependencies.

I think we're at 1) now, we should start moving to 2) with a long term goal of moving to 3).  

     brucej


-----Original Message-----
From: Chris Friesen [mailto:chris.friesen at windriver.com] 
Sent: Monday, July 30, 2018 10:51 AM
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Trying a "mirrorless" build

On 07/30/2018 11:18 AM, Jones, Bruce E wrote:
> Scott, you raised a very interesting point.
>
> I think that the tension between A and B is more about wanting to do both at the same time.  We want to provide high levels of performance and stability, pushing us toward A.  But the pain of maintaining the patches necessary and managing older package versions pushes us toward B.
>
> I think we need to find the balancing point between the two - where performance is high and the pain as low.

I think Scott's point about A is not so much about keeping the same set of packages forever, but rather that if I build a given release today and then build that same release a month (or a year) from now it should result in the same package versions in the ISO.

Theoretically I think you could have both behaviours as long as:

1) Each build using the latest upstream package versions gets an auto-generated identifier and all package versions used in that build get dumped into a mirror somewhere.
2) If you build with an explicit identifier you would use the package versions that were originally used for the identified build.

This would let you run with the latest and greatest during a development cycle, and then lock down the versions on a release branch.

Chris

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss