Bug#608263: /etc/grub.d/05_debian_theme: new 05_debian_theme doesn't allow no background image

[Alexander Kurtz]

Am Mittwoch, den 05.01.2011, 17:00 +0100 schrieb Mario 'BitKoenig' Holbe:
> Hmmm, probably we have different opinions about the focus of
> 05_debian_theme?

No, actually we don't ;-). In a perfect world 05_debian_theme would look
like this:

	#!/bin/sh
	if [ -n "${GRUB_BACKGROUND} ]; then
		GRUB_BACKGROUND="/usr/share/images/desktop-base/desktop-grub.png"
	fi

But, unfortunately this isn't a perfect world. So we have to deal with
GRUB's shortcomings (in particular those from 00_header)

> What do you intend it to be for?
> 
> My personal opinion is: 05_debian_theme is Debian-specific, it is not
> pushed upstream. Hence, it should handle the Debian-specific things, but
> nothing more.

I intend it to do exactly what you think it should do. But since we
don't live in that perfect world that requires more code than it
actually should.

> I know, 05_debian_theme is currently a very sophisticated variant of
> GRUB's comparably basic background-handling and I honestly like the work
> you did - especially the caching. I know it does some things better than
> upstream. And, of course, I understand that you like to have this work
> to be applied to the non-Debian-specific cases as well.  However, I
> personally believe you implemented this the wrong way: If you
> like to have upper case file extensions handled, if you like to have a
> cute caching for files not directly readable by GRUB, if you like to
> have a garbage collection in /boot/grub, why don't you report it
> upstream? Why do you like to keep it Debian-specific?
> I.e.: why do you put all this in 05_debian_theme instead of giving
> upstream a chance to adopt it?

I absolutely agree. Let me make this clear: Making 05_debian_theme more
or less obsolete is definitely my long term goal. But I'd also like to
have a working background image, preferably in time for squeeze. So I
chose the pragmatic way and fixed 05_debian_theme. This doesn't mean
that 00_header doesn't also need fixing. Again: I plan to do that.

> > No, the whole point is that there is no extra configuration necessary,
> 
> But there was. You changed that.
Is that good or bad?

> Strange users who try copying things somewhere and expect anything to
> happen :) ... "The wall needs to be painted. Hey, let's put a bucket of
> color close to it, I guess this will do the trick."
I think Tom Sawyer would have liked that ;-)

> > It's all about the magic words "It Just Works???".
> 
> I understand all this. But why on Debian only?
> 
> scnr again: Why on Debian at all? Doesn't this look more Ubuntu-like? :)
Again: Pushing this upstream by including it in 00_header is planned.
And why can't Debian for once be more "user-friendly" than Ubuntu? ;-)

> >  a) that's what the old 05_debian_theme did and I wanted to stick as 
> >     close to that behavior as possible
> 
> Hmmmm, wait... no, you didn't :)
Well, I tried avoiding the bugs of course...

> There is no sane default: black isnt readable on dark backgrounds, white
> isn't readable on light backgrounds, etc. If you don't agree with
> upstreams defaults, ... well, u know :)

Ok, I can give you another reason:

Without default values GRUB would throw out syntax errors, because the
lines would look like this

	set color_normal=

So I'd have to add another if-clause to check whether there have been
colors supplied and change the output accordingly. Did I mention that
I'm sometimes lazy? ;-)

> GRUB's default colors are btw. even terminal-specific (well, at least in
> principle).
Well, in that case I may actually re-think my laziness. This sounds like
a good argument to me.

Best regards

Alexander Kurtz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20110105/dc25bc13/attachment-0001.pgp>