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

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

[Radu Moisan]

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@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

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

[Samuel Stirtzel]

2013/4/2 Radu Moisan <radu.moisan@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@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

--
Regards
Samuel

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

[Radu Moisan]

On 04/02/2013 04:02 PM, Samuel Stirtzel wrote:
> 2013/4/2 Radu Moisan <radu.moisan@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@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?

Radu

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

[Samuel Stirtzel]

2013/4/2 Radu Moisan <radu.moisan@intel.com>:
>
> On 04/02/2013 04:02 PM, Samuel Stirtzel wrote:
>>
>> 2013/4/2 Radu Moisan <radu.moisan@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@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

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

[Burton, Ross]

Hi,

On 2 April 2013 15:15, Samuel Stirtzel <s.stirtzel@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.moisan@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.

> 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?

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.

Ross

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

[Samuel Stirtzel]

2013/4/3 Burton, Ross <ross.burton@intel.com>:
> Hi,
>
> On 2 April 2013 15:15, Samuel Stirtzel <s.stirtzel@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.moisan@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

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

[Richard Purdie]

On Wed, 2013-04-03 at 16:51 +0200, Samuel Stirtzel wrote:
> 2013/4/3 Burton, Ross <ross.burton@intel.com>:
> > Hi,
> >
> > On 2 April 2013 15:15, Samuel Stirtzel <s.stirtzel@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.moisan@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.

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

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.

Cheers,

Richard

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

[Samuel Stirtzel]

2013/4/3 Richard Purdie <richard.purdie@linuxfoundation.org>:
> On Wed, 2013-04-03 at 16:51 +0200, Samuel Stirtzel wrote:
>> 2013/4/3 Burton, Ross <ross.burton@intel.com>:
>> > Hi,
>> >
>> > On 2 April 2013 15:15, Samuel Stirtzel <s.stirtzel@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.moisan@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

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

[Burton, Ross]

On 3 April 2013 15:51, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote:
> 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"

Changing the default target depending on the use of the image isn't
really the same as forking systemd, and we're not making anything
incompatible.

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

Obviously the nuances of my sentiment were lost as it was transcribed to ASCII.

I'm advocating changing the default target to multi-user and then
patching the two recipes where X session scripts are packaged to also
set the target to graphical.  People switching to systemd who don't
use the standard X sessions (they roll their own, or don't use X, or
whatever) will notice quickly that the default target needs to be
changed, and can do it in their graphical startup recipes.

You're suggesting leaving the default target as graphical and changing
uncountable numbers of *image recipes* to override the default target,
the alternative being errors in the log.

So far "the community" disagrees on the approach here - we've had
vocal objections to errors in the log for any image, changing the
default target, and the other proposals.

We *do* need a way of changing the default target.  Do we at least all
agree that update-alternatives is a logical way of changing it on a
per-image basis?

Ross

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

[Samuel Stirtzel]

2013/4/3 Burton, Ross <ross.burton@intel.com>:
> On 3 April 2013 15:51, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote:
>> 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"
>
> Changing the default target depending on the use of the image isn't
> really the same as forking systemd, and we're not making anything
> incompatible.

Please read above what I wrote to Richard.

>
>>> 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.
>
> Obviously the nuances of my sentiment were lost as it was transcribed to ASCII.
>
> I'm advocating changing the default target to multi-user and then
> patching the two recipes where X session scripts are packaged to also
> set the target to graphical.  People switching to systemd who don't
> use the standard X sessions (they roll their own, or don't use X, or
> whatever) will notice quickly that the default target needs to be
> changed, and can do it in their graphical startup recipes.
>
> You're suggesting leaving the default target as graphical and changing
> uncountable numbers of *image recipes* to override the default target,
> the alternative being errors in the log.

Image inheritance will hopefully reduce the number of required changes.

>
> So far "the community" disagrees on the approach here - we've had
> vocal objections to errors in the log for any image, changing the
> default target, and the other proposals.

The seen error is a warning IIRC.
Breaking something to fix a warning somewhere else seems like a bold move.
Being incompatible with systemd standards to archive this seems to be
a very odd compromise.

>
> We *do* need a way of changing the default target.  Do we at least all
> agree that update-alternatives is a logical way of changing it on a
> per-image basis?

Yes it is required to have the possibility to change the target where needed.
I guess update-alternatives will do the job.



--
Regards
Samuel

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

On Thu, Apr 04, 2013 at 08:59:11AM +0200, Samuel Stirtzel wrote:
> 2013/4/3 Burton, Ross <ross.burton@intel.com>:
> > On 3 April 2013 15:51, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote:
> >> 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"
> >
> > Changing the default target depending on the use of the image isn't
> > really the same as forking systemd, and we're not making anything
> > incompatible.
> 
> Please read above what I wrote to Richard.
> 
> >
> >>> 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.
> >
> > Obviously the nuances of my sentiment were lost as it was transcribed to ASCII.
> >
> > I'm advocating changing the default target to multi-user and then
> > patching the two recipes where X session scripts are packaged to also
> > set the target to graphical.  People switching to systemd who don't
> > use the standard X sessions (they roll their own, or don't use X, or
> > whatever) will notice quickly that the default target needs to be
> > changed, and can do it in their graphical startup recipes.
> >
> > You're suggesting leaving the default target as graphical and changing
> > uncountable numbers of *image recipes* to override the default target,
> > the alternative being errors in the log.
> 
> Image inheritance will hopefully reduce the number of required changes.
> 
> >
> > So far "the community" disagrees on the approach here - we've had
> > vocal objections to errors in the log for any image, changing the
> > default target, and the other proposals.
> 
> The seen error is a warning IIRC.
> Breaking something to fix a warning somewhere else seems like a bold move.
> Being incompatible with systemd standards to archive this seems to be
> a very odd compromise.
> 
> >
> > We *do* need a way of changing the default target.  Do we at least all
> > agree that update-alternatives is a logical way of changing it on a
> > per-image basis?
> 
> Yes it is required to have the possibility to change the target where needed.
> I guess update-alternatives will do the job.

I agree that old implementation of this was really ugly:
http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/32492

But patchset which consistently updates all related recipes to use u-a
for default-target looks OK to me (I don't see better alternative).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Koen Kooi]

Op 3 apr. 2013, om 17:27 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 3 April 2013 15:51, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote:
>> 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"
> 
> Changing the default target depending on the use of the image isn't
> really the same as forking systemd, and we're not making anything
> incompatible.

I think the point that Samual is trying to make is that when using systemd you implicitly agree to a kind of "social contract" to not be different for the sake of being different. Samuel, please correct me if I misinterpreted what you're saying.

Let's look at an example, 2 years ago this was the accepted by upstream:

	http://cgit.freedesktop.org/systemd/systemd/commit/?id=1bd8b8184ee3bc7fc023d6d6dfb2ca99fb6612f3

But nowadays that is a big no-no:

	http://cgit.freedesktop.org/systemd/systemd/commit/?id=bc2708414babc5c99bb8000e63c84e87606cc15d

Any time you want to make a change it you should ask the systemd folks on #systemd or their mailinglist if that's the right way to do that. The systemd recipe is already a deviant by using prefix=/, but we know why that is and accept the consequences.

From what I can tell changing the default runlevel based on the image content should be OK and not make the OE systemd implementation different from all the others. But I have lost track what is being discussed here, see below.

>>> 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.
> 
> Obviously the nuances of my sentiment were lost as it was transcribed to ASCII.
> 
> I'm advocating changing the default target to multi-user and then
> patching the two recipes where X session scripts are packaged to also
> set the target to graphical.  People switching to systemd who don't
> use the standard X sessions (they roll their own, or don't use X, or
> whatever) will notice quickly that the default target needs to be
> changed, and can do it in their graphical startup recipes.
> 
> You're suggesting leaving the default target as graphical and changing
> uncountable numbers of *image recipes* to override the default target,
> the alternative being errors in the log.
> 
> So far "the community" disagrees on the approach here - we've had
> vocal objections to errors in the log for any image, changing the
> default target, and the other proposals.

I'm getting a bit lost on what the actual problem is and what kind of fixes are needed besides this patch. So can the people involved tell me what will change when I have the following:

1) console-image already using systemd, used as-is
2) gdm-image already using systemd, used as-is
3) console-image already using systemd, gdm will be opkg-installed at some point.

What will be different between 2 clean builds before and after these changes and what will happen when I 'opkg update ; opkg upgrade' those image built before the change with ipks built after the change?

> We *do* need a way of changing the default target.  Do we at least all
> agree that update-alternatives is a logical way of changing it on a
> per-image basis?

Looking at http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions it suggest using symlinks, which is what u-a does under the hood, so it looks like a decent solution to me.

regards,

Koen

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

[Samuel Stirtzel]

2013/4/4 Koen Kooi <koen@dominion.thruhere.net>:
>
> Op 3 apr. 2013, om 17:27 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:
>
>> On 3 April 2013 15:51, Samuel Stirtzel <s.stirtzel@googlemail.com> wrote:
>>> 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"
>>
>> Changing the default target depending on the use of the image isn't
>> really the same as forking systemd, and we're not making anything
>> incompatible.
>
> I think the point that Samual is trying to make is that when using systemd you implicitly agree to a kind of "social contract" to not be different for the sake of being different. Samuel, please correct me if I misinterpreted what you're saying.


Kind of, this discussion is about being compatible with systemd.

>
> Let's look at an example, 2 years ago this was the accepted by upstream:
>
>         http://cgit.freedesktop.org/systemd/systemd/commit/?id=1bd8b8184ee3bc7fc023d6d6dfb2ca99fb6612f3
>
> But nowadays that is a big no-no:
>
>         http://cgit.freedesktop.org/systemd/systemd/commit/?id=bc2708414babc5c99bb8000e63c84e87606cc15d
>
> Any time you want to make a change it you should ask the systemd folks on #systemd or their mailinglist if that's the right way to do that. The systemd recipe is already a deviant by using prefix=/, but we know why that is and accept the consequences.
>
> From what I can tell changing the default runlevel based on the image content should be OK and not make the OE systemd implementation different from all the others. But I have lost track what is being discussed here, see below.

Yes, you are right, but this patch already changes the configuration
at the root of systemd and not on a per image level.
If this patch would just enable us to make a per image level change of
the systemd behavior then it would be "the way to go".

>
>>>> 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.
>>
>> Obviously the nuances of my sentiment were lost as it was transcribed to ASCII.
>>
>> I'm advocating changing the default target to multi-user and then
>> patching the two recipes where X session scripts are packaged to also
>> set the target to graphical.  People switching to systemd who don't
>> use the standard X sessions (they roll their own, or don't use X, or
>> whatever) will notice quickly that the default target needs to be
>> changed, and can do it in their graphical startup recipes.
>>
>> You're suggesting leaving the default target as graphical and changing
>> uncountable numbers of *image recipes* to override the default target,
>> the alternative being errors in the log.
>>
>> So far "the community" disagrees on the approach here - we've had
>> vocal objections to errors in the log for any image, changing the
>> default target, and the other proposals.
>
> I'm getting a bit lost on what the actual problem is and what kind of fixes are needed besides this patch. So can the people involved tell me what will change when I have the following:

Technical this problem can be solved with this patch, but it would
break all images that use X and it is incompatible with the rest of
the world for the sake of being different.
My proposal for this solution is to use u-a to change the
default.target where needed, instead of changing the default.target in
systemd AND changing the default.target back to un-break stuff that is
functional now.

>
> 1) console-image already using systemd, used as-is
> 2) gdm-image already using systemd, used as-is
> 3) console-image already using systemd, gdm will be opkg-installed at some point.
>
> What will be different between 2 clean builds before and after these changes and what will happen when I 'opkg update ; opkg upgrade' those image built before the change with ipks built after the change?
>
>> We *do* need a way of changing the default target.  Do we at least all
>> agree that update-alternatives is a logical way of changing it on a
>> per-image basis?
>
> Looking at http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions it suggest using symlinks, which is what u-a does under the hood, so it looks like a decent solution to me.
>



--
Regards
Samuel

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

[Burton, Ross]

On 4 April 2013 08:37, Koen Kooi <koen@dominion.thruhere.net> wrote:
> 1) console-image already using systemd, used as-is
> 2) gdm-image already using systemd, used as-is
> 3) console-image already using systemd, gdm will be opkg-installed at some point.
>
> What will be different between 2 clean builds before and after these changes and what will
> happen when I 'opkg update ; opkg upgrade' those image built before the change with ipks
> built after the change?

In my world order, console-image uses the
default.target->multi-user.target as defined by systemd.  The gdm
package as it's a graphical session manager (like xserver-nodm-init)
should switch the alternative graphical.target, with a higher
priority.  This will mean that both (2) and (3) will both boot to gdm.

Ross

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

[Andreas Müller]

On Thu, Apr 4, 2013 at 4:30 PM, Burton, Ross <ross.burton@intel.com> wrote:
> In my world order, console-image uses the
> default.target->multi-user.target as defined by systemd.  The gdm
> package as it's a graphical session manager (like xserver-nodm-init)
> should switch the alternative graphical.target, with a higher
> priority.
and lightdm-kde / lxdm / opie-login...

Andreas

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

[Burton, Ross]

On 4 April 2013 16:17, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> On Thu, Apr 4, 2013 at 4:30 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> In my world order, console-image uses the
>> default.target->multi-user.target as defined by systemd.  The gdm
>> package as it's a graphical session manager (like xserver-nodm-init)
>> should switch the alternative graphical.target, with a higher
>> priority.
> and lightdm-kde / lxdm / opie-login...

Sure.  So do we want warnings in the log for non-graphical targets, or
have to change the session manager recipes for graphical targets?
This entire discussion was started because there were complaints that
minimal images were producing warnings.

Ross

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

[Koen Kooi]

Op 4 apr. 2013, om 16:30 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 4 April 2013 08:37, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 1) console-image already using systemd, used as-is
>> 2) gdm-image already using systemd, used as-is
>> 3) console-image already using systemd, gdm will be opkg-installed at some point.
>> 
>> What will be different between 2 clean builds before and after these changes and what will
>> happen when I 'opkg update ; opkg upgrade' those image built before the change with ipks
>> built after the change?
> 
> In my world order, console-image uses the
> default.target->multi-user.target as defined by systemd.  The gdm
> package as it's a graphical session manager (like xserver-nodm-init)
> should switch the alternative graphical.target, with a higher
> priority.  This will mean that both (2) and (3) will both boot to gdm.

That sounds good to me.