On Mon, 2005-02-21 at 20:12 -0500, Ned Ludd wrote: > > This is how I think and pleas correct me when/if I go wrong: > > > does busybox rpm support fetching? > No > > does busybox dpkg support fetching? > Only via interfaces like ipkg.
So, what I was thinking was: emerge ./xyz-0.1.tbz2 installs the xyz package. emerge -C xyz uninstalls it. Those functions would be fundamental. We could even write a separate epkg doing this 2 things, install a file and uninstall it, and the use a shell written emerge on top of epkg, taking care of PKGDIR, BIN_HOST etc... Starting with this to functions (install/deinstall file) would help people (atleast me) get going forward. fetching tbz2 and downloading INDEX (or Packages) files could be done in next step. > > would it be an idea to build a separate program/script that runs on top > > of busybox emerge? Something like apt-get running on top of dpkg /rpm. > > > > In many embedded environments will probably a fetch feature be overkill > > anyway. Those who really need it could write a script like: > > The basic idea with any busybox applet is to choose at compile time what > apps and features of those apps you want, so if your not interested in > said feature you are free to disable it via our busybox ebuild > USE=saveconfig option. > > The fetch code should actually pretty simple because we are working with > busybox in memory so all we have todo is build an **argv array and call > wget_main(argc, argv) from within the process (maybe fork() along the > way if needed). This will become a menuconfig option. Cool enough. but it would be nice to have *something* working. The thing is that there is more things that just fetch involved. That include downloading some kind of package database into cache, finding latest available package, checking dependencies, checking integrity (sha1, md5 sums or both or something else...), cleaning up local cache etc etc. All those things could temporary be handeled in a shell script until they are properly implemented in busybox. > > # the package name > > PKG=$1 > > > > PKG_PATH="http://myserver/myproj/tbz2"; > > CACHE="/var/cache/gentoo" > > > > # lets say Packages just contains a filelist of available packages > > # in the repository > > LATEST=$(wget -q -P $CACHE $PKG_PATH/Packages.gz | gunzip -c | \ > > grep "^$PKG-[0-9].*" ) > > > > # do error check here > > wget -P $CACHE $PKG_PATH/$LATEST > > emerge $CACHE/$LATEST > > > > > UNMERGE { /var/db/pkg/$PN/CONTENTS } > > > QUERY I'm not sure yet what this does > > > SYNC { sync host. does bb have rsync?? } > > > LIST I'm not sure yet what this does > > > UPDATE { FETCH } > > > CLEAN What files does clean clean up, anyway? > > > > > > Ben > > > > > > In any case, you could probably begin with the "install" part so it is > > possible to install packages. When that is working more functionality > > can be added. > > > Anything I could do to help? > > yes.. So far today your the second person wanting to help with this. > I think what Benjamin Collar is going todo is take the last revision I > sent him > http://oc12.net/~solar/busybox-svn-emerge-applet-20050220.diff > get a little more work done and then bounce it back to me. I'll put in > in busybox's subversion repository as a development feature and we will > hash out the rest of the features together based on the input from this > list. I have looked at it today. First I didn't really understand what you guys had in mind really, but I found this: http://oc12.net/~solar/gentoo/uclibc/emerge.sh.txt So I think I understand now. What comes up to my mind is this: A customer/user call me on the phone telling that there is a problem with xyz-0.1. I check it up and can confirm that there is really a problem in xyz. Since this is based on gentoo I just fix and emerge while the user is on the phone and send the xyz-0.1-r1.tbz2 by email. Now the user would need to either store the package at his PKGDIR/All or I would need to upload this on the "official" BINARY_HOST and regenerate the package file. It would actually be convenient (for me) if it would be possible to install a package like: emerge /media/usb/xyz-0.1-r1.tbz2 Without needing updating any index files or copying any files to a specified directory (mkdir All && cp xyz-0.1-r1.tbz2 All/ && \ emerge --pkgdir= ./ xyz) Just a thought. Another thing. the -q option. In standard emerge the -q means quiet. Could this create confution for users who believe that emerge in embedded is just like emerge in glibc gentoo? About the package database for installed packages... while discussing apk with a cooworker I was asked if the files lists/metadata could be stored compressed. He said that in the current bering based distro we are using, the filelists were uncompressed and became problematic big in some occations. So would it be possible to store the package database compressed? Other thing. Is there anything planned about pre-install/post-install, pre-delete/post-delete sripts? > For now we are skipping the idea of a flat INDEX and going with > something a little more defined closer to something like a Packages > file which we can parse easy enough. > http://dev.gentoo.org/~solar/portage_misc/genpkgindex I added a comment to the #82132 before checking up this. Sorry. Anyway, here are some thoughts. The information specified in the Package file would be downloaded twice. Once when downloading the Package file and once downloading the tbz2 package. To DSL users this does not matter, but I could make a difference if/when there are many packages and the user uses dialup. Dialup's would prefer binaries instead of compiling from source I guess. On the other hand, could this open up for future apt-get for tbz2? That would be *really* cool :-) -- Natanael Copa -- [email protected] mailing list
