On 5/8/19 12:44 PM, Victor Rodriguez wrote:
Hi team
A few weeks ago I had the curiosity to investigate if there was an rpm repo in CENGN for starling X. Scott was very kind to point me about, thanks a lot Scott. Why this is related to multi-os? RPM repositories are warehouses of RPM package files that are easy to consume to build with upstream tools like mock. mock is a tool for building RPM packages. we can use mock to build packages for many different versions of CentOS/Red Hat and Fedora.
After some experiments I was able to build basic packages from fault management using the following methodology:
1) set up mock in my Linux distro ( in my case centos 7.6 ) 2) use the following mock repositories config file to build: https://github.com/starlingx-staging/stx-packaging/blob/master/configs/docke... 3) build as: srpm : mock -r $(MOCK_CONFIG) --buildsrpm --spec=$(SPEC) --sources=$(SOURCES) --resultdir $(RES_DIR) --define="tis_patch_ver $(TIS_PATCH_VER)" rpm : mock -r $(MOCK_CONFIG) --rebuild $(SRPM) --resultdir $(RES_DIR) --define="tis_patch_ver $(TIS_PATCH_VER)"
( the variables point to the location of my spec file and source tar.gz files, the MOCK_CONFIG points to the path of my local-centos-7-x86_64.cfg file )
In the end, it works pretty straight forward, proving the following points from this experiment ( hopefully useful for someone else ) :
a) If we use the CENGN repos ( plus the centos repo ) is possible to build an RPM w/o the need to download the mirror. Great job Scott and build team! b) Is possible to use alternative upstream tools to build a single RPM w/o the need to rebuild the build dependencies.
Now a few questions came to me :
a ) Are these CENGN repos in active use, I mean, are they updated with a new ISO or every time a developer merge a commit in master? I believe that we have a stable area and that the latest also contains actual RPM repos (with repodata) in both the inputs and outputs RPMS subdirectories, so it seems that they are always generated. So it's a
Great work to Erich, Marcela and Victor! process question about when to move them the a "green" master area to work with more stable RPMS.
b) After trying to build all the packages in fault management I found that: * the source files directories are not standard ( I know Erich is working on this )
If your referring to the source located in fm-common/source or in the case of fm-api it's fm-api, or fm-client: python-fmclient/fmclient, each are different. There is a way to normalize this in the spec file by setting %setup -c <src directory> fm-common: %prep %setup -n fm-common/sources python-fmclient: %prep %setup -n python-fmclient/fmclient I learned about this trying to work with Suse / OSB example.
* there are missing BuildRequires in the current centos spec files ( they build due to the specific architecture that builds system has to handle/install the build req in a parallel build )
This is important to fix and gain the info for not just RPMs, but DEBs aswell and any future build tools.
In the aim of improving the project to some other members of the community use different tools to build different layers of the OS. I was wonder how valuable the community see the task of adding the proper BuildRequires in all the flock spec files that have missing ones. I create a launchpad and a patch for the missing build req I found in fm-rest-api:
Looks good, other than the commit message is too wide ;-0! Sau!
Any feedback from the community more than welcome
Regards
Victor Rodriguez
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss