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@linux.intel.com] Sent: Thursday, July 26, 2018 9:16 AM To: starlingx-discuss@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@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@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss