On Friday 07 November 2008 13:27:08 Cathey, Jim wrote: > But there probably needs to be a central vision of what > defconfig is and is not, one owner of record.
Er, that would be Denys. I'd like to make it very clear: I am no longer maintainer, I'm just another developer with an opinion. If Denys disagrees with me, what he says goes. I'm explaining the historical perspective, and also explaining my own use cases and the use cases I've seen. > He can take > opinions, like this one. PAM and DEBUG are pretty uncontroversial, > but whether certain more obscure BB features were on or off > for defconfig would be where the central vision comes into > play, rather than endless wrangling over it. The charter for > defconfig, however, should be well documented. svn 23952 added this comment to the top of scripts/defconfig: +# defconfig is allyesconfig minus any features that are +# specialized (debugging etc) or make applet behavior change +# significantly from "standard" version of utilities. +# Applets which are severely incompatible with "standard" utilities +# or are not maintained /tested for some time, appear to be buggy +# and carry serious potential of breakage if used, may also be excluded And also edited it to be a lot closer to that goal. (I haven't looked that closely yet to see how it differs from what I'm currently using.) I do note that I have to yank "TASKSET" from my .config in order to build on mips. (Not all embedded targets have the cpu affinity syscalls, and if you don't that won't build.) Whether or not defconfig should include that one is one of them judgement call things. (It builds fine on x86... :) Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
