All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
Subject: Re: [PATCH 0/2] psplash fixes
Date: Wed, 21 Dec 2011 15:40:03 +0000	[thread overview]
Message-ID: <1324482003.18348.5.camel@ted> (raw)
In-Reply-To: <756581D3-FAA6-48FC-9ECE-0B7CC1262A5D@dominion.thruhere.net>

On Mon, 2011-12-19 at 19:48 +0100, Koen Kooi wrote:
> Op 19 dec. 2011, om 19:32 heeft Paul Eggleton het volgende geschreven:
> 
> > On Monday 19 December 2011 19:27:06 Koen Kooi wrote:
> >> Op 19 dec. 2011, om 19:22 heeft Paul Eggleton het volgende geschreven:
> >>> On Monday 19 December 2011 18:50:35 Koen Kooi wrote:
> >>>> Op 19 dec. 2011, om 18:43 heeft Paul Eggleton het volgende geschreven:
> >>>>> Set the default psplash image to the OpenEmbedded logo, and provide
> >>>>> a
> >>>>> script to allow people to use their own custom image.
> >>>> 
> >>>> What I did in OE-classic and meta-angstrom is to use
> >>>> update-alternatives to provide different psplash images. This way you
> >>>> can choose a different splash for each image instead of having a
> >>>> distro wide one. Is something like that suitable for oe-core as well?
> >>> 
> >>> Sounds like a useful capability, however, does this mean that when you
> >>> want to override it in the image you end up with both psplash versions
> >>> installed?
> >> in a splashless image you can just do 'IMAGE_INSTALL += psplash-angstrom and
> >> it will only install that one. If you want to reuse an existing, unmodified
> >> image with psplash and add your own, then you will end up with both.
> > 
> > Although I guess another way to do it would be to do a VIRTUAL-RUNTIME type 
> > thing like we do for other such selections. At the moment in OE-core, psplash 
> > is brought in via task-core-console, and whilst it is a separate variable that 
> > could be overridden it's a task which once built really makes it impossible to 
> > customise per-image.
> > 
> > What about a "splash" IMAGE_FEATURE and then a VIRTUAL-RUNTIME_splash to 
> > select which psplash to install?
> 
> I will say again: I absolutely HATE that virtual-runtime nonsense. If
> you need to change a task, change the task, don't introduce things
> that make it non deterministic. Guess what happens when you change a
> virtual-runtime *after* you have built the task already.

That virtual-runtime stuff is clearly distro related and should only be
changed at the distro level. Doing anything else with it isn't
supported.

The splash screen issue strikes me as a distro level issue with
different distro's wanting to rebrand as needed. It therefore seems
appropriate to handle psplash that way?

Having them parallel installed seems overly complex and a solution in
search of a problem :/

And yes, personally I dislike the virtual-runtime stuff too but the
alternative is a ton of copies of recipes with one line changes which I
dislike more.

Cheers,

Richard





      parent reply	other threads:[~2011-12-21 15:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-19 17:43 [PATCH 0/2] psplash fixes Paul Eggleton
2011-12-19 17:43 ` [PATCH 1/2] psplash: use OpenEmbedded logo Paul Eggleton
2011-12-20  9:55   ` Paul Menzel
2011-12-19 17:43 ` [PATCH 2/2] scripts/contrib: add a script to create a psplash image header Paul Eggleton
2011-12-19 17:50 ` [PATCH 0/2] psplash fixes Koen Kooi
2011-12-19 18:22   ` Paul Eggleton
2011-12-19 18:27     ` Koen Kooi
2011-12-19 18:32       ` Paul Eggleton
2011-12-19 18:48         ` Koen Kooi
2011-12-19 18:57           ` Paul Eggleton
2011-12-19 19:02             ` Koen Kooi
2011-12-19 19:12               ` Paul Eggleton
2011-12-21 15:16                 ` Paul Eggleton
2011-12-20 15:31             ` Philip Balister
2011-12-21 15:15               ` Paul Eggleton
2011-12-23  0:00                 ` Philip Balister
2011-12-20  7:33           ` Martin Jansa
2011-12-21 15:40           ` Richard Purdie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1324482003.18348.5.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.