I finally decided to get this patch another go, even though still no busybox daemon has LSB headers, but I would need to ask for some prime example of LSB headers that I can start off with. Could anyone please provide me a good example for that from the Yocto project? Thanks.
On Fri, Jul 25, 2014 at 2:32 PM, Laszlo Papp <lp...@kde.org> wrote: > Any reason why this feature has never got in? It was submitted more than > five months ago, and it would have added some feature to the system even if > not _everything_ right from the beginning? > > > On Sat, Mar 22, 2014 at 2:03 PM, Laszlo Papp <lp...@kde.org> wrote: >> >> On Fri, Mar 21, 2014 at 2:39 PM, Martin Jansa <martin.ja...@gmail.com> >> wrote: >> > On Fri, Mar 21, 2014 at 01:59:15PM +0000, Laszlo Papp wrote: >> >> On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross <ross.bur...@intel.com> >> >> wrote: >> >> > On 20 March 2014 19:01, Laszlo Papp <lp...@kde.org> wrote: >> >> >> This init script is adding support for sysv and no more. This is >> >> >> also >> >> >> indicated in the first line of the commit message. I am sorry, but I >> >> >> will not test it systemd and with other systems >> >> > >> >> > You're not being asked to test with systemd. You're being asked to >> >> > add LSB-standard sysvinit-specific headers to a sysvinit script. >> >> >> >> In my understanding, people were referring to two issues: >> >> >> >> 1) not working with systemd and what not compat modes. This is not >> >> something I will test any soon. >> > >> > Other people already know it's causing the issues without LSB headers, >> > so if you just add them, you don't need to test it with systemd, other >> > people who care about systemd will do that for you or at least be OK >> > with adding this script, because it will have LSB headers (so it should >> > work fine in systemd world). >> >> If someone is really interested in systemd, et al, unlike me at this >> point, I guess it is not a big deal to get an LSB header from someone >> to get it integrated into my change? >> >> If no one cares about that, then why bother? So, if someone sends this >> to me I will integrate it, otherwise there is no point since that >> means no one cares. >> >> But then again, this should not still block the change as it can be >> added incrementally. I am not sure if it is a good idea to block a >> feature because it does not provide another feature, too. > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
