The script I sent in another thread (Adding packages to build .lst files) uses repoquery to recursively determine dependencies of packages, with commands like: repoquery --quiet -c $REPOCFG --resolve --requires --recursive From: Chen, Yan [mailto:yan.chen@intel.com] Sent: Monday, July 23, 2018 1:54 AM To: Xie, Cindy; Hu, Yong; Jones, Bruce E; Little, Scott; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] StarlingX.repo using CentOS 7.3 binary repos instead of 7.4? I guess so, currently we already get some information from the rpms. We will review the data first and I will improve the tool to get more. Yan From: Xie, Cindy [mailto:cindy.xie@intel.com] Sent: Monday, July 23, 2018 11:55 To: Hu, Yong <yong.hu@intel.com>; Jones, Bruce E <bruce.e.jones@intel.com>; Scott Little <scott.little@windriver.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] StarlingX.repo using CentOS 7.3 binary repos instead of 7.4? So I guess Chen Yan’s scripts can solve the dependencies of 2), right? From: Hu, Yong [mailto:yong.hu@intel.com] Sent: Monday, July 23, 2018 9:07 AM To: Jones, Bruce E <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>>; Scott Little <scott.little@windriver.com<mailto:scott.little@windriver.com>>; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] StarlingX.repo using CentOS 7.3 binary repos instead of 7.4? We have 2 types of dependencies to handle: 1). Build dependencies (indicated by “build requires”) and 2) deployment (installation) dependencies (indicated by “requires”). If we are aware of a new package is needed, this package name could be added into *.lst, and accordingly the package itself can be managed to download and added into the mirror. But the *indirect* dependencies brought into by this new package couldn’t be explicitly figured out until the build failures, going along with the building iterations. It would be helpful to have a script to analyze the dependency chain, BEFORE actually trying the build iterations painfully. Would love to see how Clear Linux project efficiently resolve this problem. Regards, Yong From: "Jones, Bruce E" <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>> Date: Friday, 20 July 2018 at 11:59 PM To: Scott Little <scott.little@windriver.com<mailto:scott.little@windriver.com>>, "Hu, Yong" <yong.hu@intel.com<mailto:yong.hu@intel.com>>, "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Subject: RE: [Starlingx-discuss] StarlingX.repo using CentOS 7.3 binary repos instead of 7.4? Managing the rpm dependency tree in an automated way is one of the key things I’m hoping we can learn from (leverage) from the Clear Linux project. They seem to have solved this problem. Several ex-Clear team members are on our team now and thinking about this… brucej From: Scott Little [mailto:scott.little@windriver.com] Sent: Friday, July 20, 2018 6:48 AM To: Hu, Yong <yong.hu@intel.com<mailto:yong.hu@intel.com>>; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] StarlingX.repo using CentOS 7.3 binary repos instead of 7.4? erlang*18.3.4.4*rpm are the ones to use. The R16B version should have been excluded. Yes, our mirror was of all ~30000 rpms. In this way, when a designer adds a new package or dependency, it and it's recursive dependencies were already present and ready for use. The method that has been concocted for StarlingX requires adding packages to .lst files every time there is a change. Further there doesn't seem to be a tool to assist in the search for missing dependencies. The result is likely to be several iterations of ... add package, compile, fail due to missing dependency, add package, compile, fail due to missing dependency ... very time consuming and frustrating. Scott On 18-07-19 09:00 PM, Hu, Yong wrote: Hi Scott, I noticed in the black_list, there are a couple of RPMs (such as erlang*-R16B*.rpm”), which were in tis-r4-CentOS mirror but were NOT used since tis-r5-CentOS. As well, we are certain they are not needed for building R5 or current StarlingX codebase. Could we just drop them? BTW: in tis-r5-CentOS mirror, there are over 30,000 RPMs, while actually among those only ~1900 RPMs are necessary. regards, Yong From: Scott Little <scott.little@windriver.com><mailto:scott.little@windriver.com> Date: Wednesday, 18 July 2018 at 11:17 PM To: "starlingx-discuss@lists.starlingx.io"<mailto:starlingx-discuss@lists.starlingx.io> <starlingx-discuss@lists.starlingx.io><mailto:starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] StarlingX.repo using CentOS 7.3 binary repos instead of 7.4? StarlingX should be based on Centos 7.4 for the vast majority of packages. I think there are a dozen that have made the move to 7.5. There are also a few that we blacklisted and are pulling from earlier releases. I'll attach my black_list notes as they exist today. I'll have to audit them to make sure my notes are up to date. Scott On 18-07-18 10:47 AM, Penney, Don wrote: Hi all, The StarlingX.repo file in stx-tools has all the CentOS 7.4.1708 binary repos disabled and is instead using 7.3.1611. This would likely explain why some of the specified RPMs cannot be downloaded via yum, as they were upversioned in 7.4. Was this done for a particular reason, or is it a configuration error? Don Penney, Developer, Wind River _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io<mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss