Hello Cedric, > Hi Eric, > > That sounds great. > Is there already something we can test/hack ?
I have an image I can send you this evening (UTC) when I'm home. If there is more demand, maybe it can be placed somewhere on the LEAF site. > Any idea on the timeline, especially for the (long awaited) uClibc upgrade > ? > Not yet, it depends on everyones free time ;)) The move to a new config system and/or uClibc upgrade touches every package setup in buildtool, so although it's not very difficult to do it costs time. Also every package needs to be rebuilded and tested. > > What about a 3-way diff tool during upgrade process ? We would then > have a really upgradable system. > That would be nice, but could be implemented afterwards. The question is if it's really needed. If the changes between package versions/revisions are compatible, it's just a matter of replacing the package. If the changes are incompatible, the question is if a 3-way diff tool works. Anyway, with this new config system you only have to diff one package (the "configdb") instead of each and every package. > > Regards, > Cedric > Regards, Eric > > 2006/6/11, Eric Spakman <[EMAIL PROTECTED]>: > >> Hello list, >> >> >> The Bering-uClibc crew is working on a new config/backup system. In >> this system config changes are no longer saved in the package itself but >> in a seperate "configdb" package. The same is true for modules, which >> are saved in a "moddb" package. >> >> This is done because several users suggested to split the configuration >> from the binaries. >> >> The config system only saves the changed files, keeping the overhead to >> a minumum. It is partly based on apkg by Nathan and Nathaneal. It works >> as follows (somewhat simplified): -At startup (pre-init) the sha1-sums >> of files listed in a <package>.local file are calculated and saved in a >> <package>.sha1 file. The files listed >> in <package>.local are user changable files like config files and f.e. >> ssh-keys -At backup time the contents of the <package>.sha1 is compared >> with the actual files on the system and only the changed files are >> backuped. This is done for all packages on the system and only one >> "configdb" is >> created with changes from all packages. It's also dynamic so files no >> longer available on the system (the package is removed) will be removed >> from it. >> >> Some of the advantages: >> -Upgrading should be easier in most cases (config is preserved) >> -It is possible to create specific "configd" and "moddb" packages for >> specific hardware or functionality without creating special packages >> (WRAP, ...) >> -The packages are "static", so no more corruption or "growing" root.lrp >> -<package>.list and <package>.exclude.list can be removed >> >> >> Because this system creates some package incompatibility (no more .list >> files) we plan to do this with an uClibc upgrade (which isn't >> backwards compatible also). The changes are not very drastic and >> relative easy implemented in buildtool, so we could make the change >> without a lot of effort. >> >> Comments? >> >> >> Regards, >> Eric >> >> >> >> >> >> _______________________________________________ >> leaf-devel mailing list leaf-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/leaf-devel >> >> > > > > _______________________________________________ > leaf-devel mailing list leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel > > _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
