Not to mention, there is a huge difference between build time regression and run time, so I disagree.
a)-c) can just as well be done after this change with the same loss. Do not blame me for introducing build (!) regressions, and then you have got a situation like this. If you feel it serious, write a change on top of mine. On Mon, Jul 29, 2013 at 11:22 AM, Laszlo Papp <lp...@kde.org> wrote: > I disagree. This change should not have gone in the first place causing > the regression for the users. Please be consistent with the history. > > > On Mon, Jul 29, 2013 at 11:20 AM, Phil Blundell <p...@pbcl.net> wrote: > >> On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote: >> > No, that was intentional. That is why the change has been updated. >> > >> > >> > I can update the commit message if that is what you wish? >> >> As a general rule yes, please always make sure that the commit message >> describes what the patch is actually doing. >> >> But in this particular case, your new patch seems to have more serious >> problems since it will cause rfkill to silently disappear for many >> people who do currently have it. >> >> If your distro selects a toolchain which doesn't contain the necessary >> bits to support rfkill then it seems as though the appropriate course of >> action would be to either: >> >> a) patch rfkill so that it does build with your headers; or >> >> b) introduce a PACKAGECONFIG option for busybox to turn off rfkill even >> if it would naturally default to on, and set this in your distro >> configuration; or >> >> c) just add your own .bbappend for busybox to do what you want. >> >> p. >> >> >> >> >
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
