Re: [gentoo-embedded] overlay-specific keywords / use flags for cross-compiling

[Christopher Friedt]

Nevermind, I think I managed to discover where I went wrong - in 
portage, one needs to add the ~<arch> flag in 
/etc/portage/package.keywords to equivalently set 
ACCEPT_KEYWORDS="~<arch>" then?

The strange thing, is that on my plain-old i686 laptop, i usually just 
say 'sys-app/busybox' without the ~<arch> and it manages to set 
ACCEPT_KEYWORDS for that package to ~<arch> ....

wierd!

Christopher Friedt wrote:
> Hi Nedd,
>
> Thanks for your reply - i've been crazy busy lately.
>
> The ROOT & PORTAGE_CONFIGROOT directories are the same, and I tested out
> /sysroot/etc/portage/package.use. That works no problem.
>
> However, i still don't see an effect if I do something in package.keywords.
>
> I usually do this on my desktop machine if I'd like to open up the
> keywords for a particular package. Am I doing something wrong?
>
>
> vaiprime / # echo "sys-apps/busybox" >>
> /sysroot/etc/portage/package.keywords
> vaiprime / # xmerge -pv busybox
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild   R   ] sys-apps/busybox-1.2.2.1 to /sysroot/ USE="static*
> -debug -make-symlinks -netboot -savedconfig" 1,380 kB
>
> vaiprime / # ACCEPT_KEYWORDS="~arm" xmerge -avB busybox
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild     U ] sys-apps/busybox-1.3.1 [1.2.2.1] to /sysroot/
> USE="static* -debug -make-symlinks -savedconfig (-netboot%)" 1,456 kB
>
> Ned Ludd wrote:
>> Is your $SYSROOT the same as your $PORTAGE_CONFIGROOT?
>> Cuz portage only looks in $PORTAGE_CONFIGROOT and cares nothing of
>> $SYSROOT..
>>
>>
>> On Sat, 2007-01-13 at 00:12 +0100, Christopher Friedt wrote:
>>> Hi everyone,
>>>
>>> I've set up a 'build root' that I can chroot into for cross development.
>>> There is also a directory of targets to compile for, and for each
>>> target, a series of different configurations.
>>>
>>> When I chroot into my buildroot my 'enter_chroot' script will
>>> automatically mount -o bind each of the sysroot, binpkgs, and overlay
>>> directories for a specified configuration, as well as mount -o bind
>>> the portage tree itself.
>>>
>>> So my directory structure looks something like this:
>>>
>>> gentoo-crossdev-buildroot/
>>>    enter_chroot.sh
>>>      (mounts proc, mounts -o bind portage/sysroot/binpkg/overlay etc)
>>>    portage/
>>>      ... (the portage tree)
>>>    buildroot/
>>>      ... (all cross compilation tools and a stage1 filesystem)
>>>    targets/
>>>      arm-9tdmi-linux-gnu/
>>>        cross-toolchain/
>>>        configurations/
>>>          reference/
>>>            overlay/
>>>            binpkgs/
>>>            sysroot/
>>>          client1/
>>>            ...
>>>          client2/
>>>            ...
>>>      arm-9tdmi-linux-uclibc/
>>>        cross-toolchain/
>>>        configurations/
>>>          reference/
>>>            overlay/
>>>            binpkgs/
>>>            sysroot/
>>>          client1/
>>>            ...
>>>          client2/
>>>            ...
>>>
>>> What I'm hoping to do is leverage the power of portage overlays here,
>>> and make it possible to have different package customizations for
>>> each client and each platform that my company deals with.
>>>
>>> It doesn't take a lot to see that this is a great way to minimize
>>> maintenance.
>>>
>>> My problem though, is that when doing cross development (I use the
>>> xmerge scrypt and set a SYSROOT variable), I have noticed that when I
>>> set new flags in $SYSROOT/etc/portage/package.use, it's not noticed
>>> properly during emerge.
>>>
>>> I'm hoping that portage can be flexible enough to acknowlege those
>>> use flags. The xmerge script (taken from one of the gentoo cross
>>> development guides online) properly sets the PORTAGE_CONFIGROOT
>>> variable, ROOT, etc, so I don't understand why it doesn't acknowlege
>>> the changes in $SYSROOT/etc/portage/package.use.
>>>
>>> Any suggestions?
>>>
>>>
>>> Regards,
>>>
>>> ~/Chris
-- 
gentoo-embedded@g.o mailing list