Bug#608519: grub-pc: 05_debian_theme assumes background image was copied from an installed desktop-base

[Alexander Kurtz]

Hi,

I am sorry for the discomfort my script has caused. I'll try to explain
my intentions:

Earlier versions of GRUB's postinst copied `moreblue-orbit-grub.png'
to /boot/grub/ unconditionally. That was a bad idea because this

 a) wasn't necessary for all users - on many machines GRUB could 
    have loaded the image directly from /usr/
 b) didn't work anymore when the default artwork changed for squeeze
 c) cluttered /boot/grub/
 d) used valuable disk space on /boot/ (which many people have on 
    separate and very small partitions)

So I tried to
 a) improve the current behavior
 b) deal as best as possible with the old, broken behavior

My solution for b) was to search for files under /boot/grub/ which match
certain criteria (filename and checksum) that made sure I wouldn't
delete somebody's wedding photos and remove those files if it was safe
to do so.

As explained earlier I don't see any way to distinguish between the case
where you put the file under /boot/grub/ and the case where GRUB's
postinst did that. To 05_debian_theme both cases look the same.

The only real solution to your problem is to simply remove the offending
code completely. I plan to do that, but only after squeeze's release.
meanwhile you can simply use a different name for the picture.

So, after all this is more of a political decision than a technical one.
I therefore believe  that the package maintainer should decide what's
the correct thing to do. However, I guess he's agreeing with my decision
since he initially accepted that code.

Let my try to answer your questions in detail:

Am Sonntag, den 02.01.2011, 19:11 +0000 schrieb Brian Potkin:
> Surely there is no difference between user-generated and user-installed
> files? In either case the user wants the file on the machine(s) and
> would not expect the packaging system to delete it. It is unfortunate
> the installed file is identical to one in a desktop-base. As you point
> out it is the history of 05_debian_theme which is the cause of the
> deletion. However, cp -a may not have helped if the file had been copied
> from the archive using the -a option.
Yes, it's a bad situation. A compromise doesn't seem to be possible. I
hope you understand my reasons taking this way.

> Reinstalling and renaming works fine, as does putting it in a different
> location. But should it happen in the first place?
It did already happen in the past. Consider this excerpt from the old
version of GRUB's postrm script:

	case "$1" in
	  purge)
	[...]
		  rm -f /boot/grub/{grub.cfg,ascii.pf2,unicode.pf2,moreblue-orbit-grub.png,*.mod,*.lst,*.img,efiemu32.o,efiemu64.o,device.map,grubenv,installed-version} || true
		  rm -rf /boot/grub/locale
		  rmdir --ignore-fail-on-non-empty /boot/grub || true
	[...]
	esac

As you can see, the old version of the postrm script also removed
`moreblue-orbit-grub.png' from /boot/grub/ when purged regardless
whether you replaced it with your wedding photo or similar. My code does
at least check whether it is safe to do so (checksums).

> What are the consquences of the script not deleting what you call old or
> obsolete files? Would leaving out that section affect the quality of the
> grub-pc package to any great extent?
Yes, please see above for a detailed list of consequences.

Am Sonntag, den 02.01.2011, 19:32 +0000 schrieb Brian Potkin:
> It did exactly what is was designed to do - except the file had not been
> provided by an installed desktop-base but had been put there by me. This
> has, to my knowledge, never happened to me before. What should be my
> expectation if I install files outside of $HOME or /usr/local?
You should not expect anything.

> Indeed, provided I notice their disappearence.  But should I placed in
> that situation?
No, you shouldn't. I would have avoided it if possible, but it wasn't.
And you definitely haven't *lost* any data.

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/20110102/84a14e67/attachment.pgp>