[OE-core] [PATCH v4] systemd: set default.target to multi-user.target

Samuel Stirtzel s.stirtzel at googlemail.com
Tue Apr 2 14:15:18 UTC 2013


2013/4/2 Radu Moisan <radu.moisan at intel.com>:
>
> On 04/02/2013 04:02 PM, Samuel Stirtzel wrote:
>>
>> 2013/4/2 Radu Moisan <radu.moisan at intel.com>:
>>>
>>> This fixes a service dependency issue;
>>> While graphical.target is the default mode, systemd
>>> will try to start display-manager.service which is not
>>> available.
>>>
>>> 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.moisan at intel.com>
>>> ---
>>>   meta/recipes-core/systemd/systemd_199.bb |    2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/recipes-core/systemd/systemd_199.bb
>>> b/meta/recipes-core/systemd/systemd_199.bb
>>> index ba1d133..bf1eb39 100644
>>> --- a/meta/recipes-core/systemd/systemd_199.bb
>>> +++ b/meta/recipes-core/systemd/systemd_199.bb
>>> @@ -248,6 +248,7 @@ update-alternatives --install ${base_sbindir}/halt
>>> halt ${base_bindir}/systemctl
>>>   update-alternatives --install ${base_sbindir}/reboot reboot
>>> ${base_bindir}/systemctl 300
>>>   update-alternatives --install ${base_sbindir}/shutdown shutdown
>>> ${base_bindir}/systemctl 300
>>>   update-alternatives --install ${base_sbindir}/poweroff poweroff
>>> ${base_bindir}/systemctl 300
>>> +update-alternatives --install ${systemd_unitdir}/system/default.target
>>> systemd-def-target ${systemd_unitdir}/system/multi-user.target 1
>>>   }
>>>
>>>   pkg_prerm_systemd () {
>>> @@ -256,6 +257,7 @@ update-alternatives --remove halt
>>> ${base_bindir}/systemctl
>>>   update-alternatives --remove reboot ${base_bindir}/systemctl
>>>   update-alternatives --remove shutdown ${base_bindir}/systemctl
>>>   update-alternatives --remove poweroff ${base_bindir}/systemctl
>>> +update-alternatives --remove systemd-def-target
>>> ${systemd_unitdir}/system/multi-user.target
>>>   }
>>>
>>>   pkg_postinst_udev-hwdb () {
>>> --
>>> 1.7.9.5
>>>
>> Reliving a dejavu?
>>
>> This was already rejected before see [1], hope you remember this.
>>
>> [1]
>> http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034806.html
>
> It was not rejected, have you seen a nack from Ross? Actually I just checked
> a few days ago with Ross and the reason it didn't merge was because it
> didn't apply anymore. And because systemd upgrade to v199 was pending I
> waited for that one to get pulled in. So now with systemd_199 in, here is my
> rebased v3 as well.
>
> There is a bug filled for this problem Bug#3816, do you have a better
> solution in mind?

Sorry, my terminology may be different.
For me rejected means that the community did not agree with a change,
otherwise I would have stated that it was NACKed previously.


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).

Every developer who designed a component for (or based upon) the
system assumed that it is using the default behavior.
But this patch breaks this behavior for incoherent reasons.

With this change all other modules have to be adapted for this
behavior instead of just "let it work as it was designed".


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.


PS: I really hope that this statement is plausible enough to not jump
into the abyss of changing software in a way it was not designed.
PPS: If you would have sent this yesterday I would have taken it for
an "April Fools' Day" hoax [1]


[1] For people unaware of this "informal holiday"
http://en.wikipedia.org/wiki/April_Fools%27_Day

--
Regards
Samuel




More information about the Openembedded-core mailing list