Re: [gentoo-embedded] small replacement for emerge for live package-management?

[Ned Ludd]

On Sun, 2008-02-03 at 15:30 +0100, Christopher Friedt wrote:
> Hi everyone,
>
> Are there any pointers for a light(er) weight package manager for
> embedded devices with <= 16 MB of flash storage ?
>
> I've grown accustomed to using emerge to build binary packages for all
> of my boards. Up until now we've just blasted the binary packages onto
> our boards in the shop, but we're turning towards updates on live
> systems in the field.
>
> Paludis has struck my interest but I'm just not sure what the runtime
> requirements are, and how well it deals with normal gentoo binary tbz2's
> (and their metadata). I think that libstdc++.so is a bit too big for our
> boards, so any options with C++ dependencies are likely out the door.
>
> Having python on our boards is not really an option either, and
> therefore the factory 'emerge' also won't work (or will it??).
>
> Does anyone have any suggestions? I'm sure that some of you have dealt
> with the same problem before.

Having has the same need myself I wrote in c a util called qmerge.
qmerge is apart of portage-utils. portage-utils provides applets much in
the same way as busybox does that can be disabled at compile time.
qmerge only deals with gentoo based binary.tbz2 files. 

# Setup basic embedded ROOT...

uClibc shm  # mkdir ROOT; cd ROOT ; mkdir proc root sys dev
uClibc ROOT # \
  INSTALL_MASK="*.a /bin/bb /usr/lib/*.o /usr/include" \
  ROOT=$PWD/ \
  emerge -KOq uclibc busybox portage-utils

uClibc ROOT # tar -xf /usr/share/busybox/busybox-links.tar
uClibc ROOT # rm -rf usr/share/busybox
uClibc ROOT # du -hcs . 
2.2M    .
uClibc ROOT # mkdir usr/portage/packages/ var/tmp/portage/portage
uClibc ROOT # cp /etc/resolv.conf  etc/
uClibc ROOT # mount -obind /proc/ proc/ ; mount -obind /sys/ sys/ ;
mount -obind /dev/ dev/

uClibc ROOT # chroot . /bin/sh --login

# Inside of the chroot or on an embedded device with networking.
/ # export QMERGE=1
/ # qmerge -KOq dropbear
MD5:  [OK] 4176096ccf8680d595de20514e65d928 net-misc/dropbear-0.50

/ # dbclient 
dbclient: can't load library 'libz.so.1'
/ # qmerge -K zlib
Connecting to tinderbox.dev.gentoo.org (140.211.166.181:80)
zlib-1.2.3-r1.tbz2   100% |
***************************************************************************************************************************************************|   139k --:--:-- ETA
MD5:  [OK] 5db12eac15c6910c179e4be1fd7bf030 sys-libs/zlib-1.2.3-r1
=== sys-libs/zlib-1.2.3-r1
+++ sys-libs/zlib-1.2.3-r1 == sys-libs/zlib-1.2.3-r1
>>> //lib/libz.so.1.2.3
>>> //usr/lib/libz.so
>>> //usr/lib/libz.a
>>> //usr/include/zconf.h
>>> //usr/include/zlib.h
>>> //var/db/pkg/sys-libs/zlib-1.2.3-r1


# opps looks like we never set up a make.conf and made sure to set an
INSTALL_MASK=..

/ # dbclient 
Dropbear client v0.50
Usage: dbclient [options] [user@]host [command]
Options are:
-p <remoteport>
-l <username>
-t    Allocate a pty
-T    Don't allocate a pty
-N    Don't run a remote command
-f    Run in background after auth
-y    Always accept remote host key if unknown
-i <identityfile>   (multiple allowed)
-L <listenport:remotehost:remoteport> Local port forwarding
-g    Allow remote hosts to connect to forwarded ports
-R <listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 24576, larger may be faster, max
1MB)
-K <keepalive>  (0 is never, default 0)



# well there we go.. One portage gentoo pkg built on a remote host and
installed on the local one that we did not have to alter server side in
any way..


/ # qsize portage-utils
app-portage/portage-utils-0.1.29: 17 files, 2 non-files, 163.667 KB


###########
Few notes.. These can be mounted by the embedded device as a tmpfs.
$ROOT/usr/portage/packages/ var/tmp/portage. You can/should delete the
contents in there on embedded devices.

1) Never make/allow qmerge to touch the libc
2) Never make/allow qmerge to touch the *busybox*/bin/sh..

Final note.. It's still an applet in development. If you find a bug in
it. I'd much would rather have a patch that fixes it up vs a bugzilla
entry telling me whats wrong with it. Good luck.



-- 
gentoo-embedded@l.g.o mailing list