On Mon, 2006-06-12 at 15:37 +0200, Eric Spakman wrote: > Hi Nataneal, > > But the, what happens if you try to upgrade apk-tools? after apk_delete, > > there are no apk_add to install the new package. I solved it by first > > unpacking the new package, then compare the lists and remove all files > > that are in old list but not in new list. (reverse sorted so files are > > removed before dirs) > > > Instead of apk_delete / apk_add you could also do a apk_add only and > overwrite the old version. You could temporary save the old list file and > compare with the new one, removing the files not in the new list.
that was what i was trying to say :) thats exactly what apk_add -u does. > You have > to stop/start a daemon if that's what has to be updated ofcourse. not here yet. but apk_add looks for and executes pre-update and post-update where its possible start/stop daemons, or simply killall -HUP ... <snip> > > > >> For the list: > >> Currently the first device in PKGPATH is the "backup" device where > >> configs and modules live (and ofcourse packages if PKGPATH has only one > >> entry, just as it is now). > > > > Why not having a separate variable? What if first device in PKGPATH is a > > cdrom? > > > In most cases (HD/Flash/Floppy) the first device is the backup device, > having a seperate variable would only introduce redundancy. But I was > thinking about adding a menu entry where an user can select the backup > device and defaulting to the first device. > In the leaf.cfg file, where PKGPATH is defined, a note is added that the > first device is the backup device. An user has to define the rw media > first. But the choice to use a seperate variable or not is only a minor > technical change, it can easely be implemented. Not sure about it yet. I'd suggest to add a CFGDEV and default it to: CFGDEV=$PKGPATH Then can the user choose himself. /nat _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
