[arch-general] build help needed, Trinity kdebase - 2 issues on Arch

David C. Rankin drankinatty at suddenlinkmail.com
Sun Feb 6 23:33:32 EST 2011


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


More information about the arch-general mailing list