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. 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" >> As alternative of changing the default I would propose that a >> specialization overrides this symlink where needed, and the >> generalization stays unchanged (like OOP inheritance). >> Therefore a specialization would be image configurations or >> postinstall appends for images that have no need for the graphical >> user target. > > How would you implement this? Register the alternative in systemd.bb > defaulting to graphical, and then switch it in every image recipe in > oe-core/meta-oe/etc that doesn't use an X or Wayland (patches coming > shortly) session? If this works why not? It sounds like a good idea, because this way would not break anything, and we would be compatible with the standard systemd. > > The bigger question to me is how to handle the alternative in a way > that doesn't create the symlink if we're not using systemd. I am not sure if this works, but couldn't the presence of systemd be detected (e.g. in the image task list)? Or alternatively the configuration of the [image|distro]-feature could be checked (wherever systemd is usually set nowadays). -- Regards Samuel _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
