On Fri, 2005-02-11 at 16:28 +0100, Benjamin Collar wrote: > Right on. I'll see what I can pull off this weekend. > > Ben > > On Fri, 2005-02-11 at 10:25 -0500, Ned Ludd wrote: > > Good morning list. > > > > If you have c skills and would like to help out the Gentoo Embedded > > project then I have a task for you. One of our favorite applications in > > the embedded world is /bin/busybox. BusyBox needs a few hrs of code > > loving put into it. Currently BusyBox only supports rpm and deb, so this > > is the next logical step. The task if you choose to accept it will be to > > code a very minimal emerge.c busybox applet. The applet will need to > > meet the following requirements. > > > > 1) The ability to fetch a native portage built package .tbz2
You can probably hook into the existing bb wget framework here for fetching. > > 2) No changes in package format handling. > > (ie no .ipk/.apk/.homebrew) This may be of use. http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/src/tbz2tool.c?root=gentoo-src A portage built package more or less is a bzip2 level 9 compressed tarball with some extra metadata concatenated to the end of the tbz2ball and a small header. The metadata is discarded at install time but would prove useful to parse to ensure that we are fetching a binary package that matches our devices mini make.conf (ie does CHOST= in the metadata match the CHOST= that we are about to install a pkg for) While doing this you will encounter the fact that we can not simply source in this metadata into ash. This means we lose pkg_preinst() pkg_postinst() functionality. For this I have no idea what would be the proper way to proceed. Installing bash is not really an option because it relies on ncurses and curses/bash requires a whole mess of deps that we are uninterested in having on such devices. > > 3) The ability to record the contents of a package exactly the same way > > portage does. (/var/db/pkg/$PN/CONTENTS) The CONTENTS files will add some extra space to the device. I'll see what I can do about getting this file to become a compressed file in a future portage release. Either .bz2 or .gz You might also find this useful. http://oc12.net/~solar/verify_contents.c We might want to make this feature optional as some ppl may wish to install one time (into a ramfs/tmpfs) and forget about it and or limited by space constraints. > > 4) The ability to uninstall a binary package based on whats in listed in > > the CONTENTS file. > > 5) The ability to omit files from being installed based on a setting > > called INSTALL_MASK. This should behave exactly like the current portage > > implementation if the INSTALL_MASK feature which accepts globing. > > ex: INSTALL_MASK="*.a /usr/lib/*.o /usr/include *.pl" > > 6) use the bb api as much as you can (ie the socket code etc is mostly > > already there provided by libbb.a) > > 7) Not take many weeks/months to do. > > 8) And mostly importantly have fun doing it. > > > > Now I know a few of you on this list have to be c coders so I'm > > attaching a very basic non working standalone mock up that's 50% c and > > 50% ash to give you a rough idea of what we are thinking. > > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux
signature.asc
Description: This is a digitally signed message part
