It's desired to have a way to rebuild binary RPMs, from an SRPM on the target. This will likely require a change to the archive code to produce SRPMs that are likely able to be rebuilt on the target. This may also require a change to the 'rpmbuild' configuration on the target to support any special needs for the target SRPMs.
Dear Mark, Does this following 2 scenarios: 1) Can we re-build SRPM on the Host itself ?? (by setting cross enviroment) But, in this case generated RPMs from Yocto should be re-locatable which is not as of currently. 2) Are you only targeting to re-build SRPM on "target side" only? - boot the target - build the srpm using "rpmbuild -ba abc.srpm" Please clarify. Regards, Gaurang Shastri
(In reply to comment #1) > Dear Mark, > > Does this following 2 scenarios: > > 1) Can we re-build SRPM on the Host itself ?? (by setting cross enviroment) > > But, in this case generated RPMs from Yocto should be re-locatable which is > not as of currently. Possible, but this was not part of the original request. It would require correct wrapper information and the right version of RPM and RPM macros to control the build in a way that is similar to the regular cross-development system. > 2) Are you only targeting to re-build SRPM on "target side" only? > - boot the target > - build the srpm using "rpmbuild -ba abc.srpm" The above was the purpose of this request. Construct both RPM and SRPM packages in the cross development system, and be able to rebuild select packages on the target itself. By select packages I was thinking of things that are routinely modified by users. These would include the kernel and out of tree kernel-module packages. Various server or networking packages like net-snmp, apache, etc. It would be nice to be able to rebuild the whole system, but probably not required.
>>It would be nice to be able to rebuild the whole system, but probably not >>required. But in this case, how would you segregate only particular packages?? I mean, if you are writing logic for srpm(probably create correct spec file), then it should apply to all (all target packages). Please correct me if I misunderstood.
Some packages have very simple build and compilation rules. They do not rely on significant custom steps, nor on python OE classes (beyond the simply rules of configure, make, make install..) Those are the types of packages that should be fairly easy to convert into an SRPM that can be built on the target. For packages that use significant python code, or other specialized helpers from the OE world -- it may not be easy to "adapt" them to working in the SRPM environment. Most of the 'complicated' packages (QT for instance) are not typically things that -my- customers would recompile on a target system.
At this time, it's no longer believed this makes sense to attempt.
aggreed