Hi Nataneal, >> Correct, although it's somewhat difficult to remove a package without a >> .list file. >> > > apk-tools create the package listing on the fly. Something like: > > tar -ztf package.apk > var/db/apk/package/CONTENTS tar -zxf package.apk > That can also be implemented in Bering-uClibc, seems like a nice addition.
> The challenge is the upgrades. I thought it was easy: > apk_delete package (old one) apk_add package (new one) > > 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. You have to stop/start a daemon if that's what has to be updated ofcourse. >> Currently package removing is not implemented, although an >> implementation where a package list is created dynamicaly (with tar -ztf >> at boottime) should be possible. I'm not sure if package removing is >> worth the hassle, it has a lot of corner cases so the easiest way to >> remove a package without problems is to remove it from the load list and >> reboot :) That's one of advantages of a system in RAM. >> > > Except that for us, the reason to do upgrades is to avoid reboots. We > want high uptimes. (and sacrifice some size for that) > I also want high uptimes but was more thinking about an implementation as above when upgrading without the removal of the package first. <snip> >> Some text is missing? >> > > umm.. *blush* i think i went to lunch and forgot it. sorry. I dont remeber > what i was thinking and it was probably not important. > > ah.. yes probalby that you need a wrapper script on top of the pakcage > manager. The wrapper scripts installs the package and creates the > checksums. Then you could use any package manager. > Correct, in our case the packages are installed and checksums are created in linuxrc (initrd) before the package manager is even installed. > But I have started to think that it can be hard to implement. > > <snip> >>> So after the local config is loaded, I replace the entries in the >>> commited.tdb (recreate the checksums for those files) >>> >> Our approach is to load the "configdb" package as last package in >> linuxrc, so before init is started. The files in the configdb will >> overwrite the existing config files pre-init so those are used instead >> of the ones in the packages themselve. The sha1sums of the original >> files in the packages are calculated before that. > > Thats basicly the same as we do. Execpt alpinelinux can load > packages/configs from different locations (usb *and* floppy). For example, > its possible to only store network configs on floppy, and load packages > needed to get NFS working (portmap is the only package needed for that), > then load a new package.list from nfs and load packages + configs from nfs > in a later boot stage. Got it working last saturday. > We can also load packages from different locations, PKGPATH is just a list of devices where packages can be found. >> Ofcourse this means that the backup system can't see if a change is >> saved before, it always notes a difference (the calculated sha1 sum is >> from the original package). This doesn't matter that much because the >> "configdb" >> package is small, so saving is fast and it also makes sure "old" files >> are removed from the configdb package. > > Yes. and you actually dont need to see what files have changed either. > You need to save them all anyway (all the files that differs from > package) It just that we want a reminder displayed on web config that you > need to save to local media or you will lose config in next reboot. > > so: > > > if lbu status -q ; then # no need to save. display a green icon of some > sort else # need to save. display a red icon of some sort > echo "Please remeber to save configs to floppy" fi > > <snip> > Very nice. > >> 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. <snip> > -- > Natanael Copa > Eric _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
