Glad to see Gentoo-openmoko distro

Al Johnson openmoko at
Thu Sep 11 01:56:14 CEST 2008

On Wednesday 10 September 2008, Previdi Roberto wrote:
> On Wed, Sep 10, 2008 at 1:22 AM, Al Johnson
> <openmoko at>wrote:
> > No loss of USE - see the Gentoo Embedded Handbook, in particular this
> > page:
> >
> >
> >p=5
> Ok, i have read that document, i think you are referring to the part where
> he says
> *"For your runtime system, you'll need a much slimmer/trimmed down setup.
> The files you remove from a normal installed package is why this tree is
> not suitable for compiling against. If you build binary packages while
> installing into your sysroot, then you can use those binary packages in
> conjunction with the INSTALL_MASK variable to trim out most things. See the
> make.conf(5) man page for more information."
> *But i cannot understand a thing: why if i only have one neo, and i don't
> plan to release any overlay or similar to the public, should i choose to
> prepare the binary packages on the desktop and then emerge them from the
> neo? Isn't it the same thing of just syncing the two trees? umh..
> Anyway, i have thought a bit about the available options to keep the
> installation clean.. i came to 2+1 solutions:
> 1) concurrent tree
> we keep 2 different trees, one on the neo and one on the desktop. when we
> want to update, install, remove, destroy any piece of our little gentoo
> thing we just make an operation of "sync-emerge-sync".
> we must make the first sync to import in the desktop any modified
> configuration file, any custom installed lib, or deletion of things..
> the second sync is obviously to transfer the newly updated files on the neo
> pros:
> - two copies are better than one (simple and up to date backup)
> - you can make the painful "after holiday world update" (which can compile
> for something like one night on slow desktops) and other slow operations
> without keeping the neo connected. just make the first sync and then launch
> the command
> - versioning?
> - eventual neo disconnections during the sync phase are not so terrible, we
> just reconnect and restart the sync..
> cons:
> - much space occupied
> - the sync can be very slow (because the flash card is slow)
> 2) on-desktop compilation - on-neo installation
> we mount the neo root as sysroot on the desktop (nfs? usbfs?). then we add
> to the mounted tree the missing directories (/usr/portage,
> /var/tmp/portage, /usr/doc and others) which will actually reside on the
> desktop disk. now we have a complete sysroot where we can execute the
> cross-emerge as explained in the guide. after that we simply unmount our
> neo and go out with our freshly updated system.
> pros:
> - faster, no tedious sync involved
> - less space required on the desktop
> cons:
> - you must keep the neo connected all the time
> - neo disconnection can cause emerge to fail (but it shouldn't create
> inconsistencies, until the disconnection happens in the installation phase)
> - maybe other problems due to discording user ids or something (?)
> 3) hybrid (my preferred one)
> we keep both the clone tree and the mounting scripts, we mount the neo over
> the clone tree (and complete with the links) when we want a simple and
> wuick update of 2 or 3 packages. But when we must compile the heavy
> 65-packages gnome+qt+apache+openoffice update we just make the sync, launch
> the command and come back after the necessary hours..
> pros: flexibility
> cons: cannot find one (maybe paranoia? personality conflicts? :) )
> please guys tell me what you think about.. maybe there are much simpler
> ways that i forgot or just don't know about..
> roby

I think you're making this much harder than it needs to be. It's very much 
like the OpenEmbedded situation, except we're using portage to build binary 
packages for the Freerunner instead of using bitbake. The desktop is the 
repository for the binary packages. On the Freerunner you can 
netmount /usr/portage, or keep it local if you have the space to spare, and 
sync against the desktop buildhost. Point portage on the freerunner to the 
desktop as the binary package repository, and emerge binary packages only. 

More information about the community mailing list