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.
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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
