On 02/06/2011 09:05 PM, Ray Rashif wrote:
On 7 February 2011 10:38, David C. Rankin
<drankinatty@xxxxxxxxxxxxxxxxxx> 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.
