Hi Eric,
That sounds great. Is there already something we can test/hack ? Any idea on the timeline, especially for the (long awaited) uClibc upgrade ? What about a 3-way diff tool during upgrade process ? We would then have a really upgradable system. Regards, Cedric 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
