Patchwork [0/2] psplash fixes

login
register
mail settings
Submitter Paul Eggleton
Date Dec. 19, 2011, 5:43 p.m.
Message ID <cover.1324316137.git.paul.eggleton@linux.intel.com>
Download mbox
Permalink /patch/17261/
State New
Headers show

Pull-request

git://git.openembedded.org/openembedded-core-contrib paule/oe-psplash

Comments

Paul Eggleton - Dec. 19, 2011, 5:43 p.m.
Set the default psplash image to the OpenEmbedded logo, and provide a
script to allow people to use their own custom image.

Note: there's a corresponding meta-yocto patch which should be applied
after this set.

The following changes since commit ae4118a1f78f113c3d687c3aa6a86007cf977cae:

  libsdl 1.2.14: fix packaging (2011-12-19 12:17:36 +0000)

are available in the git repository at:
  git://git.openembedded.org/openembedded-core-contrib paule/oe-psplash
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/oe-psplash

Paul Eggleton (2):
  psplash: use OpenEmbedded logo
  scripts/contrib: add a script to create a psplash image header

 meta/recipes-core/psplash/files/psplash-img.h      | 1062 ++++++++++++++++++++
 meta/recipes-core/psplash/files/psplash-poky-img.h |  909 -----------------
 meta/recipes-core/psplash/psplash_git.bb           |    6 +-
 scripts/contrib/make-psplash-img-header.sh         |   22 +
 4 files changed, 1087 insertions(+), 912 deletions(-)
 create mode 100644 meta/recipes-core/psplash/files/psplash-img.h
 delete mode 100644 meta/recipes-core/psplash/files/psplash-poky-img.h
 create mode 100755 scripts/contrib/make-psplash-img-header.sh
Koen Kooi - Dec. 19, 2011, 5:50 p.m.
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?

regards,

Koen
Paul Eggleton - Dec. 19, 2011, 6:22 p.m.
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?

Cheers,
Paul
Koen Kooi - Dec. 19, 2011, 6:27 p.m.
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.

regards,

Koen
Paul Eggleton - Dec. 19, 2011, 6:32 p.m.
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? Would update-alternatives be needed at all in 
that case?

Cheers,
Paul
Koen Kooi - Dec. 19, 2011, 6:48 p.m.
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.

> Would update-alternatives be needed at all in 
> that case?

It would if you want to change it after booting :)
Paul Eggleton - Dec. 19, 2011, 6:57 p.m.
On Monday 19 December 2011 19:48:48 Koen Kooi wrote:
> 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.

This is the problem I'm trying to avoid. Perhaps it wasn't clear, but what I 
meant was change things so we do not bring in psplash via a task anymore - 
instead use the value of VIRTUAL-RUNTIME_splash within core-image.bbclass, 
controlled via an IMAGE_FEATURE.

> > Would update-alternatives be needed at all in
> > that case?
> 
> It would if you want to change it after booting :)

What's the use case for changing the splash image after booting?

Cheers,
Paul
Koen Kooi - Dec. 19, 2011, 7:02 p.m.
Op 19 dec. 2011, om 19:57 heeft Paul Eggleton het volgende geschreven:

> On Monday 19 December 2011 19:48:48 Koen Kooi wrote:
>> 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.
> 
> This is the problem I'm trying to avoid. Perhaps it wasn't clear, but what I 
> meant was change things so we do not bring in psplash via a task anymore - 
> instead use the value of VIRTUAL-RUNTIME_splash within core-image.bbclass, 
> controlled via an IMAGE_FEATURE.

In OE-classic we had IMAGE_SPLASH. Btw, I'm not using core-image.bbclase.

>>> Would update-alternatives be needed at all in
>>> that case?
>> 
>> It would if you want to change it after booting :)
> 
> What's the use case for changing the splash image after booting?

If you splash contains text its nice to be able to exchange it as easily as the rest of the system.
Paul Eggleton - Dec. 19, 2011, 7:12 p.m.
On Monday 19 December 2011 20:02:02 Koen Kooi wrote:
> In OE-classic we had IMAGE_SPLASH. Btw, I'm not using core-image.bbclase.

Well we could always use IMAGE_SPLASH and bring it in via image.bbclass. It 
seems to me like something you should be able to enable or exchange easily for 
any image.
 
> >>> Would update-alternatives be needed at all in
> >>> that case?
> >> 
> >> It would if you want to change it after booting :)
> > 
> > What's the use case for changing the splash image after booting?
> 
> If you splash contains text its nice to be able to exchange it as easily as
> the rest of the system.

So is this for i18n? Or do you have something in the text that's likely to 
need changing? Might it be better to provide an alternative channel for 
displaying text in psplash for that?

Cheers,
Paul
Martin Jansa - Dec. 20, 2011, 7:33 a.m.
On Mon, Dec 19, 2011 at 07:48:48PM +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.

The advantage of virtual-runtime is that something like initscripts, is
pulled by more than one recipe, so in order to change initscripts pulled
to distro images you have to change 3-4 recipes by .bbappend and bump PR
in all.

With VIRTUAL-RUNTIME you have to select VIRTUAL-RUNTIME_initscripts by
distro config and add .bbappends only with PRINC bumps for recipes using
this variable (easy to find with git grep).
And if someone else adds new recipe also using initscripts then he
should use right one wrt VIRTUAL-RUNTIME_initscripts not expecting you
to notice that other recipe pulling initscripts is there (I've used
BLACKLIST to notice those before, but VIRTUAL-RUNTIME is better).

And it's like DISTRO_FEATURES, nobody should change VIRTUAL-RUNTIME
settings without at least PRINC bumps.

Cheers,
Philip Balister - Dec. 20, 2011, 3:31 p.m.
On 12/19/2011 01:57 PM, Paul Eggleton wrote:
> On Monday 19 December 2011 19:48:48 Koen Kooi wrote:
>> 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.
> 
> This is the problem I'm trying to avoid. Perhaps it wasn't clear, but what I 
> meant was change things so we do not bring in psplash via a task anymore - 
> instead use the value of VIRTUAL-RUNTIME_splash within core-image.bbclass, 
> controlled via an IMAGE_FEATURE.
> 
>>> Would update-alternatives be needed at all in
>>> that case?
>>
>> It would if you want to change it after booting :)
> 
> What's the use case for changing the splash image after booting?

I can see people taking an existing image, adding a few packages to
customize it for their application, and changing the splash image to a
product specific one.

Philip
Paul Eggleton - Dec. 21, 2011, 3:15 p.m.
On Tuesday 20 December 2011 10:31:52 Philip Balister wrote:
> I can see people taking an existing image, adding a few packages to
> customize it for their application, and changing the splash image to a
> product specific one.

I'm not entirely convinced this workflow makes sense when you're interested in 
getting reproducible product images. This is basically the "take some existing 
distro and hack it up until it fits" approach which taken past a certain point 
leads to an unmaintainable mess, or at the very least regressions.

People really ought to be able to produce their final images from the metadata 
with no additional post-build changes (or at least none that are manual). If 
that's too difficult, that's the problem I think is most worthwhile to attack, 
even if it requires more work on our part.

Cheers,
Paul
Paul Eggleton - Dec. 21, 2011, 3:16 p.m.
On Monday 19 December 2011 19:12:10 Paul Eggleton wrote:
> On Monday 19 December 2011 20:02:02 Koen Kooi wrote:
> > In OE-classic we had IMAGE_SPLASH. Btw, I'm not using
> > core-image.bbclase.
> 
> Well we could always use IMAGE_SPLASH and bring it in via image.bbclass. It
> seems to me like something you should be able to enable or exchange easily
> for any image.
> 
> > >>> Would update-alternatives be needed at all in
> > >>> that case?
> > >> 
> > >> It would if you want to change it after booting :)
> > > 
> > > What's the use case for changing the splash image after booting?
> > 
> > If you splash contains text its nice to be able to exchange it as easily
> > as the rest of the system.
> 
> So is this for i18n? Or do you have something in the text that's likely to
> need changing? Might it be better to provide an alternative channel for
> displaying text in psplash for that?

Ping - if you help me to understand what you're trying to achieve then we can 
try to figure out the best way to solve it.

Cheers,
Paul
Richard Purdie - Dec. 21, 2011, 3:40 p.m.
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
Philip Balister - Dec. 23, 2011, midnight
On 12/21/2011 10:15 AM, Paul Eggleton wrote:
> On Tuesday 20 December 2011 10:31:52 Philip Balister wrote:
>> I can see people taking an existing image, adding a few packages to
>> customize it for their application, and changing the splash image to a
>> product specific one.
> 
> I'm not entirely convinced this workflow makes sense when you're interested in 
> getting reproducible product images. This is basically the "take some existing 
> distro and hack it up until it fits" approach which taken past a certain point 
> leads to an unmaintainable mess, or at the very least regressions.
> 
> People really ought to be able to produce their final images from the metadata 
> with no additional post-build changes (or at least none that are manual). If 
> that's too difficult, that's the problem I think is most worthwhile to attack, 
> even if it requires more work on our part.

Well, I can see people wanting to do this. It falls into the case of the
customer is always right, even when he is wrong :)

Philip