2013/4/3 Richard Purdie <richard.pur...@linuxfoundation.org>:
> On Wed, 2013-04-03 at 16:51 +0200, Samuel Stirtzel wrote:
>> 2013/4/3 Burton, Ross <ross.bur...@intel.com>:
>> > Hi,
>> >
>> > On 2 April 2013 15:15, Samuel Stirtzel <s.stirt...@googlemail.com> wrote:
>> >>>>> For xserver-nodm-init we would then have something like:
>> >>>>> inherit update-alternatives
>> >>>>> ALTERNATIVE_${PN} = "systemd-def-target"
>> >>>>> ALTERNATIVE_TARGET[systemd-def-target] =
>> >>>>> "${systemd_unitdir}/system/graphical.target"
>> >>>>> ALTERNATIVE_LINK_NAME[systemd-def-target] =
>> >>>>> "${systemd_unitdir}/system/default.target"
>> >>>>> ALTERNATIVE_PRIORITY[systemd-def-target] ?= "10"
>> >>>>>
>> >>>>> Signed-off-by: Radu Moisan <radu.moi...@intel.com>
>> >
>> > This really needs to be a series of two patches, with this change
>> > implemented too.
>> >
>> >> To comment on this change:
>> >> A developer would expect that a system (hardware or software) behaves
>> >> in a specific matter (the default behavior).
>> >> By changing the default, the system behavior is undefined (as the
>> >> default behavior was changed).
>> >
>> > The behaviour is not undefined, it's perfectly clear - the default
>> > target is multi-user unless changed, and by patching the X startup
>> > recipes in oe-core and meta-oe we handle the majority of cases.
>>
>> When we decide that we handle standard behavior different than the
>> rest of the world, then this patch is basically a fork of systemd.
>
> No, we're not forking systemd, we're talking about configuration.
>
> This is like saying that booting your Linux desktop at a different
> runlevel is forking Linux.No, by changing a standard configuration that requires other changes to repair things that are already working you are far beyond configuration. > >> Also we tell every affected software developer: >> "No your software won't work with OE-core / Yocto Project without >> adaption, we are incompatible with the systemd standard to make life >> more comfortable for (some of) us" > > We're saying that graphical init scripts need to somehow tell the system > they're a graphical init script. There are only a small number of these > out there and adding some identification to them whilst an annoyance, > isn't a big issue. No, you are saying the default in systemd is non-graphical target. Why not tell the system that a non-graphical image needs multi-user.target? It would be compatible to the rest of the world and would archive the effect you want. > > Integrating new technology like systemd into older systems is hard. You > sometimes need to add new information to allow the system to work > properly. This is once such case. This change is not related to the struggle of upgrading from sysvinit to systemd. Even new systems may have this problem, and I don't tell you to ignore it, but I am trying to contribute to fix it properly. I hope we can get a solution without the avalanche that breaks everything affected for no necessary reason. -- Regards Samuel _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
