systemd: set default.target to multi-user.target
PATCH v4 1/1 systemd: set default.target to multi-user.target
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"
--- meta/recipes-core/systemd/systemd_199.bb | 2 ++ 1 file changed, 2 insertions(+)
meta/recipes-core/systemd/systemd_199.bb +2 -0
@@ -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 () {
Signature · 1 line
1.7.9.5
2013/4/2 Radu Moisan <[email protected]>:
Quoted 38 lines
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 <[email protected]>--- meta/recipes-core/systemd/systemd_199.bb | 2 ++ 1 file changed, 2 insertions(+)meta/recipes-core/systemd/systemd_199.bb +2
-1@@ -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 () { --
Quoted 2 lines
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
Quoted 43 lines · Samuel Stirtzel
2013/4/2 Radu Moisan <[email protected]>:
Quoted 38 lines
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 <[email protected]>--- meta/recipes-core/systemd/systemd_199.bb | 2 ++ 1 file changed, 2 insertions(+)meta/recipes-core/systemd/systemd_199.bb +2
-1@@ -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 () { --Quoted 2 lines
1.7.9.5
Reliving a dejavu?
Quoted 3 lines
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
2013/4/2 Radu Moisan <[email protected]>:
Quoted 62 lines · Samuel Stirtzel
Quoted 55 lines
2013/4/2 Radu Moisan <[email protected]>:
Quoted 47 lines
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 <[email protected]>--- meta/recipes-core/systemd/systemd_199.bb | 2 ++ 1 file changed, 2 insertions(+)meta/recipes-core/systemd/systemd_199.bb +0
-0@@ -248,6 +248,7 @@ update-alternatives --install ${base_sbindir}/halthalt ${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 () {meta/recipes-core/systemd/systemd_199.bb +0
-0@@ -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
}Quoted 4 lines
pkg_postinst_udev-hwdb () {
--
1.7.9.5Reliving a dejavu?
Quoted 4 lines
This was already rejected before see [1], hope you remember this.
[1]
http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034806.html
Quoted 8 lines
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_199in, 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
Hi,
Quoted 10 lines · Samuel Stirtzel
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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 <[email protected]>
This really needs to be a series of two patches, with this change implemented too.
Quoted 5 lines
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.
Quoted 6 lines
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
2013/4/3 Burton, Ross <[email protected]>:
Quoted 23 lines
Hi,
Quoted 10 lines · Samuel Stirtzel
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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 <[email protected]>This really needs to be a series of two patches, with this change implemented too.
Quoted 5 lines
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).
Quoted 3 lines
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"
Quoted 11 lines
Quoted 6 lines
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.
Quoted 3 lines
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
Quoted 24 lines · Samuel Stirtzel
2013/4/3 Burton, Ross <[email protected]>:
Quoted 23 lines
Hi,
Quoted 10 lines · Samuel Stirtzel
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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 <[email protected]>This really needs to be a series of two patches, with this change implemented too.
Quoted 5 lines
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).
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
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
2013/4/3 Richard Purdie <[email protected]>:
Quoted 29 lines · Samuel Stirtzel
Quoted 28 lines
2013/4/3 Burton, Ross <[email protected]>:
Quoted 26 lines
Hi,
Quoted 10 lines · Samuel Stirtzel
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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 <[email protected]>This really needs to be a series of two patches, with this change implemented too.
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 5 lines
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.
Quoted 4 lines
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
Quoted 6 lines · Samuel Stirtzel
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.
Quoted 8 lines
Quoted 4 lines
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
2013/4/3 Burton, Ross <[email protected]>:
Quoted 11 lines · Samuel Stirtzel
Quoted 6 lines
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.
Quoted 19 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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
Quoted 51 lines · Samuel Stirtzel
2013/4/3 Burton, Ross <[email protected]>:
Quoted 11 lines · Samuel Stirtzel
Quoted 6 lines
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.
Quoted 19 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.Quoted 1 line
Quoted 6 lines
Quoted 3 lines
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).
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Op 3 apr. 2013, om 17:27 heeft "Burton, Ross" <[email protected]> het volgende geschreven:
Quoted 11 lines · Samuel Stirtzel
Quoted 6 lines
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.
Quoted 18 lines
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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?
Quoted 3 lines
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
2013/4/4 Koen Kooi <[email protected]>:
Quoted 11 lines
Op 3 apr. 2013, om 17:27 heeft "Burton, Ross" <[email protected]> het volgende geschreven:
Quoted 8 lines · Samuel Stirtzel
Quoted 6 lines
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"
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
Let's look at an example, 2 years ago this was the accepted by upstream:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=1bd8b8184ee3bc7fc023d6d6dfb2ca99fb6612f3
Quoted 7 lines
But nowadays that is a big no-no:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=bc2708414babc5c99bb8000e63c84e87606cc15dAny 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".
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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?
Quoted 3 lines
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
Quoted 7 lines · Koen Kooi
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
Quoted 5 lines · Ross
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
Quoted 7 lines · Andreas Müller
Quoted 5 lines · Ross
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
Op 4 apr. 2013, om 16:30 heeft "Burton, Ross" <[email protected]> het volgende geschreven:
Quoted 9 lines · Koen Kooi
Quoted 7 lines
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?
Quoted 5 lines
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.