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
signature.asc
Description: This is a digitally signed message part
