2013/4/4 Koen Kooi <k...@dominion.thruhere.net>: > > Op 3 apr. 2013, om 17:27 heeft "Burton, Ross" <ross.bur...@intel.com> het > volgende geschreven: > >> On 3 April 2013 15:51, Samuel Stirtzel <s.stirt...@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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
