regarding my original posting where i mused about adding a git-based patch directory ...
On Sat, 2 Feb 2008, Felix Fietkau wrote: > While I like the idea for being able to better stay up to date with > latest kernels, I want to avoid having too many different patch > versions around in our svn. So a change that would allow the build > system to do what you described would be accepted in OpenWrt, but > updates of kernel patches against random git versions is probably > more something for private branches. Maybe we could keep patchsets > like that as an overlay on git.openwrt.org, as soon as the our new > server is operational. i understand entirely, i wasn't actively pushing that idea, i was just thinking out loud, but let me think out loud a little bit longer. being able to keep up with the latest repo version of a SW component (say, the kernel, gcc, glibc, binutils, etc.) would require only one extra patches sub-directory per component. so for gcc, for instance, you have the existing patch directories 3.4.6, ..., 4.2.2. to that (and all other software components you'd like to support like this), you'd just add a new sub-directory "repo", which would represent the patches against the absolutely latest repo (be it a git repo, svn repo, or whatever.) now, is this worth the trouble? first, the obvious benefits: it would be handy to be able to test against the bleeding edge software if you were feeling ambitious. and sometimes that's helpful if you don't like surprises down the road. also, it's fairly easy to implement something like this. as i mentioned before, when a new software version comes out and a new patch directory is created for it (gcc 4.2.3?), you'd immediately create an updated patches directory for gcc-4.2.3, then (re)create a sibling "repo" directory that consists of nothing but symlinks back to that new patch directory since, at that instant, those patches would be identical. once the repo starts to progress and some of those fixed version patches fail to apply, it's easy to take each failing patch, make a copy of it in the "repo" directory and fix it. and keep doing this little by little to keep up with the software repository. and whose job would that be? simple -- not felix's, but whoever wants to build against the repository. anyone who's happy with a fixed version has no obligation to care about the "repo" patches. but if you're a developer that does, then it's your job to stay on top of things and keep testing those patches and submit fixes for them as necessary. now here's the downside. there's no point even thinking about this if a builder can't *select* one of those repo versions to be used in the build, and that's not currently supported in the "make menuconfig". part of the reason, i'm guessing, is that there are only certain combination of software that work for certain architectures, and that's hard-coded into the Config.in files, if i'm reading that correctly. for instance, if i'm building for a WL500gP, the file target/linux/brcm47xx/Makefile tells me right up front: LINUX_VERSION:=2.6.23.1 so i have no freedom to override that, so that whole repo thing for the kernel wouldn't help me at all. what would have to be added is a config feature that lets you override that hardcoding if you want to try combinations that aren't proven to work. perhaps a menuconfig option along the lines of: [ ] Choice of unknown and untested software versions? and doing that would allow you to live dangerously and select completely untried combinations of software, and if the build blows up, well, too bad. :-) i'll admit i haven't looked closely enough at how much work that would be but, as a start -- even without this whole repo concept -- would it be hard to add that config option above so that builders could try different combinations of software that aren't guaranteed to work just to see what happens? at a minimum, it would be nice to try to build with the 2.6.24 kernel if i'm feeling ambitious. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook: http://crashcourse.ca/wiki/index.php/Fedora_Cookbook ======================================================================== _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
