On 02/06/2011 09:05 PM, Ray Rashif wrote:
On 7 February 2011 10:38, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
This fails with makechrootpkg because nothing gets copied to the chroot. Is there a way to fix this?
Yes, the copying is "hardcoded". Things in the source array are copied, and along with those additionally the changelog and install scriptlet. See line 170 onwards of makechrootpkg.
Unfortunately, aside from directly editing makechrootpkg itself, I don't see how to 'fix' this. Maybe if you changed the way you're going about doing the builds..but I'll have to look a little deeper to actually comment any further.
Thanks Ray, I could shoot myself. I originally did the PKGBUILDs to do a svn checkout in src, but then didn't want to re-download a complete copy of the tree every time makepkg was run. I was using a snvversion test on the .svn/entries to see if a new version existed, but that didn't do what I wanted. The good news is that adding the code to the PKGBUILD to have them do a svn checkout is a simple 5-10 lines at the top of each PKGBUILD. My overall goal was to write a shell script that would take the standard trinity svn checkout, add the PKGBUILDs, then loop through the modules in the proper build order to provide a complete build of trinity for those that don't want to use the binary packages. Easier on the dev to. Just kick off a build, go do something else, check back, still running, go do something else.... or stop and fix what broke. I guess I was using a 'tree' focused approach: Saying "I have the tree", now let's do PKGBUILDs for the tree and then tie them together with a master build script. The alternative would be the PKGBUILD focused approach: Saying "Let's build PKGBUILDs to retrieve their part of Trinity via svn and if we build them all, then we will have the whole svn tree after we build the las module. I originally shied away from this approach in order to use the simple 'svn up *' in the trinity base directory to coordinate updates to all modules and eliminate the possibility that the download of a single module and update there may put it out of sync with the rest of the tree if dependent packages below it received updates relied upon by the module you are working on. The makearchroot tool may be what drives me back to this approach. I can get i686 done in VBox, but I can't do x86_64 in Virtualbox even on a 64-bit box. So makearchroot work for the 'in source' build would be ideal. Too bad I can't just define srcdir as '../' such that the existing svn source would get into the chroot. Ideas? -- David C. Rankin, J.D., P.E.