[Starlingx-discuss] on our mirror proposal/milestone

[Jones, Bruce E]

We might want to use the technique that the Clear Linux team uses.  When they create a new release they create a new yum repo with all the contents hard linked to the previous repo.  Anything that is changed in the repo breaks the links.  This way they have exactly what they released for any release and space utilization is minimal.

     brucej

-----Original Message-----
From: Saul Wold [mailto:sgw at linux.intel.com] 
Sent: Thursday, July 26, 2018 9:16 AM
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] on our mirror proposal/milestone



On 07/26/2018 08:50 AM, Dean Troyer wrote:
> On Thu, Jul 26, 2018 at 10:33 AM, Scott Little 
> <scott.little at windriver.com> wrote:
>> I'd caution you that the list of 'hard to get' packages is ever 
>> changing due to both internal and external factors.  Certainly none 
>> of the EPEL content is safe.
>>
>> In particular, for StarlingX releases, you'll probably want to 
>> snapshot all packages that went into the release.
> 
> Exactly.  Scott, is there currently a record somewhere in the build 
> tree or ISO of what was actually used?  I suppose in the ISO we can 
> just look at the embedded repo, correct?
> 
> Related, is there anything currently recorded regarding the 
> branch/commit of the git repos for a particular build?  What I think 
> we might want to re-create a specific build might be a re-written repo 
> manifest (default.xml) that includes tags or commit SHAs...
> 
Yes, getting a good manifest of the tarball related items would be the right thing to do.

I know we have mentioned the shifting sands of RPMs, should we also be concerned about any of the tarballs disappearing (due to version change) or git repos deleting branches that we have used?

Sau!

> dt
> 

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