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

[Mario 'BitKoenig' Holbe]

On Wed, Jan 05, 2011 at 05:39:33PM +0100, Alexander Kurtz wrote:
> Am Mittwoch, den 05.01.2011, 17:00 +0100 schrieb Mario 'BitKoenig' Holbe:
> > My personal opinion is: 05_debian_theme is Debian-specific, it is not
> > pushed upstream. Hence, it should handle the Debian-specific things, but
> 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.

That's not the point... I personally pretty much like the way you
encapsulated set_background_image() - this makes it easier to move
it upstream some day.
The point is that you re-use this "more code" to (re-)do
non-Debian-specific things, too.

You re-do GRUB_BACKGROUND because you think you can do better than
00_header - which may not be wrong (except the colors :)), but it's not
05_debian_theme's job and may clash with others not expecting it.

You do handle images in /boot/grub unsolicited
a) without even knowing them, for example, without knowing what colors
   would make sense for them.
b) without others knowing or even expecting that you do this (see
   below).
Btw: Both could IMHO be a reason for upstream not to accept such
behaviour.

> 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

Let me guess - another one than spacefun from Squeeze? :)

> 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.

For the meantime not to mix them both up too much, how about using
something like GRUB_DEBIAN_BACKGROUND or DEBIAN_GRUB_BACKGROUND instead
of GRUB_BACKGROUND for "the more sophisticated Debian way to handle GRUB
images"?
You wouldn't even have to care about migration: if somebody uses it, he
has to modify /etc/default/grub manually anyways - which would later
come back to his attention through debconf.

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

I don't like to decide that.

IMHO it's bad for existing systems which now unexpectedly get a
graphical console just because they had something lingering around in
/boot/grub they probably didn't even know about.
I mean, if you install desktop-base you expect (to some extent) to get a
shiny gleamy look everywhere, but if you don't...

Probably it's also bad for systems that have other ways of setting up a
grub-background which includes copying images to /boot/grub. You now set
them up a graphical console and you don't know if you (re-)do it before
or after them, i.e. if you probably make it worse.

Directory-based plugin-mechs are never easy, as all the *.d directories
and their different behaviour show, but they all start with a very basic
principle: everybody has to know that something is a plugin-directory.

> > >  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...

But you removed my line which explained what I really meant with
"wait... no": The previous behaviour of 05_debian_theme was to install
moreblue-orbit-grub.png from desktop-base with matching colors if
possible. If not, set colors for the text interface.
But now you even remove moreblue-orbit-grub.png (which is fine with me,
btw.) - thats not close to the previous behaviour :)

Btw: Even though the removal of moreblue-orbit-grub.png is fine with me,
I personally don't like the way to do it: it was installed in a package
control script, it should be removed in a package control script.

> Without default values GRUB would throw out syntax errors, because the
...
> So I'd have to add another if-clause to check whether there have been

Great idea! ...scnr :)


Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20110105/5b4ac4e2/attachment-0001.pgp>