On Aug 19, 2007, at 1:45 PM, Andy Green wrote:

>
>> There are many reasons to attempt remote execution of build  
>> scriptlets, not
>> just to have %{_target_cpu} on remote != local.
>
> Well I can't say anything about these other uses because they are  
> out of
> scope for my experience.
>

I was thinking of remote job submission and using a server for  
compilation speed ...

>> There is nothing whatsoever stopping you from using --dbpath (or  
>> change
>> %_dbpath)
>> to have rpmbuild use multiple rpmdb's. Throwing massive amounts of
>
> Not sure I made the original point clearly, this is talking about
> different build dependencies depending on whether the dependent  
> package
> should be on the host in native form or in the _target_cpu chroot in
> target form.
>
> So you might need to have yacc in host form to build the package,  
> but it
> also needs libxyz-devel in target-specific form in the _target_cpu
> chroot --> (just an illustration, don't shoot me)
>
> BuildRequires: yacc  # as usual
> ForeignBuildRequires:
> %{_topdir}/rpm/devel-filesystem-%{_target_cpu}/var/lib/rpm libxyz- 
> devel
> # ensure libxyz-devel is present in the build chroot for _target_cpu
>

Ah got it. That's basically where the thread started with per-arch  
changes,
some of which can/will affect src.rpm content, including srpm metadata.

For pure metadata like BuildRequires: I at one point implemented a  
archScore(...) filter
that turned dependencies on/off depending on what value of % 
{_target_cpu} was
specified. Noone used, got in my way so I ripped it out.

Adding a path-to-targetcpu-rpmdb context specifier is likely too  
cumbersome to be useful imho.


>> cross-packaged garbage into
>> a single rpmdb and expecting rpm to sort out the mess is naive. I
>> certainly cannot justify
>> my time expenditure to support the vanishingly small needs of cross
>> compilation build hosts.
>
> Oh well, the subject came up... the only work proposed is some way to
> query against a second rpmdb, but one only needs it for improved
> build-time diagnostics about not having the right packages in the  
> right
> places, I'm not even asking for it, just pointing out that AFAIK it is
> useful and can't be done right now.

Adding a loop over rpmdb's is slowly approaching the top of the todo  
stack.
Been asked for since 1999 ...

>> Meanwhile I'd certainly like to see more cros-compilation used.  
>> What I
>> actually see is
>> that few have the time/energy to maintain cross-tool chains, and who
>> have the methodolgy
>> and discipline to setup cross build machines, all using *.rpm  
>> packages.
>>
>> Note "all using *.rpm packages" qualifier.
>
> Not sure what you mean by this.  Currently if you want to cross-build
> something needing a library, you crosscompile the library and then
> install library-devel into the _target_cpu chroot and build against  
> what
> you just installed... this is indeed all using *.rpm packages.  Unless
> you mean how the cross compiler itself was packaged?
>

I'm not aware of any robust cross-compile build system based solely  
on *.rpm packages.

I am aware of some good cross-compile build systems, just not based  
on *.rpm.

73 de Jeff