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. > Ok :))
<snip> >> 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. > Good suggestion didn't thought about that, but PKGPATH can be a list and the first entry can still be a CDROM. I'm not sure if it's obvious if backup fails that the above entry can be the fault, if a note is added in the leaf.cfg file that the first entry is the backup device in the PKGPATH it could be clearer. But I'm still not sure what to do... > > /nat > > Eric > _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
