Hello Cedric, >> Not sure, now that we tag the sources it should be easier to checkout a >> specific version. Making a seperate branch would introduce extra work >> and take extra time we don't have.. > > Yes, but what about 2.4.x bugfix releases while this long process of > upgrading every package to the new toolchain ? > The primary goal of the buildtool toolchain is for development. An option is to provide packages only for 2.4.x bugfixes, afterall the bugfixes will make it to the main branch also so it should be possible to simple backport those to a private checkout of the 2.4.x version. It's just a question of time and progression. I agree that a branch would be nice, but we simply don't have the time to work on it and do development at the same time.
> Is there any TODO list for the toolchain ? > Not really, the most important things are updating uClibc and gcc. > > >> [...] The current system is really very simple and >> doesn't use extra tools like diff and patch. Besides config files (text >> files) compress very good so the result will probably be a lot smaller >> than introducing new requirements. > > Of course, but patch.c is only 7k in busybox and a stripped down > version of diff shouldn't be too big > True, but it's still the question if the added complexity will be worth it and if the result is smaller. Once the choice is done to backup changes seperate from the packages, improvements in "userspace" (backup in a database or store diffs) can be done without touching the packages itself. It would be really nice to see something like this in a proof of concept, I'm especially interested in how to implement a "merge" or "patch" when a config file is changed a bit upstream. For example placement of config items in a different order or added optional items in a config file can break the "patch". > Regards, > Cedric > Regards, Eric _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
