[Starlingx-discuss] on our mirror proposal/milestone
So i just want to get our story straight on the mirror milestone What we are working for, is to mirror the things that are a moving target, hard to get packages that are outside the centos repos and hosted by third party entities which are initially 9 packages. My assumption is that outside these 9 packages, everything else is reachable and we have reliable-ish sources for rpms Moving forward, the next wave of packages that we will plan to host, will be those packages who are not hosted on centOS repos, and if we need to add things to the intel hosted mirror due a third party or centOS repos retiring those packages, we will take those packages to our internal approval process to mirror those. please share your thoughts Regards Cesar Lara Software Engineering Manager OpenSource Technology Center
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. Scott On 18-07-26 11:16 AM, Lara, Cesar wrote:
So i just want to get our story straight on the mirror milestone
What we are working for, is to mirror the things that are a moving target, hard to get packages that are outside the centos repos and hosted by third party entities which are initially 9 packages.
My assumption is that outside these 9 packages, everything else is reachable and we have reliable-ish sources for rpms
Moving forward, the next wave of packages that we will plan to host, will be those packages who are not hosted on centOS repos,
and
if we need to add things to the intel hosted mirror due a third party or centOS repos retiring those packages, we will take those packages to our internal approval process to mirror those.
please share your thoughts
Regards
*//*
*/Cesar Lara/*
Software Engineering Manager
OpenSource Technology Center
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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... dt -- Dean Troyer dtroyer@gmail.com
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
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
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
On Thu, Jul 26, 2018 at 10:33 AM, Scott Little <scott.little@windriver.com> wrote: tree or ISO of what was actually used? I suppose in the ISO we can just look at the embedded repo, correct? [SL] $MY_WORKSPACE/export/dist/isolinux/Packages/ contains all the
On 18-07-26 11:50 AM, Dean Troyer wrote: packages added to the iso, excluding anything unique to the initrd (just anaconda think). There is no single record of rpms required by to satisfy all the BuildRequires. I'de try a query like this cd $MY_WORKSPACE grep -i 'Installing :' --no-filename */results/jenkins-CGCS_6.0_Host-2018-07-19_11-30-21-tis-r6-pike-std/*/root.log | awk '{ print $5 }' | sort --unique For both queries, some rpms will by unique to StarlingX, or contain release values suggesting it's stx patched.
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...
[SL] I do have code to do that in our jenkins build jobs. I can move it into the build scripts if we have a story to cover it.
dt
participants (5)
-
Dean Troyer
-
Jones, Bruce E
-
Lara, Cesar
-
Saul Wold
-
Scott Little