Description of Problem:
I have 22 lines of .mailcap which I did not put there defining various OpenOffice
programs to open should I want to view attachments in my mailer (mutt). If OOo
is actually editing my dotfiles, I think I should be warned.
Version-Release number of selected component (if applicable):
RH 8.0 upgraded from RH beta-before-that, with openoffice-1.0.1-8.
I have deleted the "how to reproduce" because I don't know yet.
This box is unfortunately not an entirely fresh install or upgrade. It was RH 7.3,
then all of /home was rsync'd elsewhere when the disc began to die. I stuck the
beta on it, and rsync'd /home back. Then I later upgraded from beta to RH 8.0
I very very rarely have cause to edit my .mailcap and didn't think to check the
last altered date before editing the file (and spotting these lines).
However, I am not even sure I have used OpenOffice on this account before. If
I have done, it was an "open it to check a launcher works" sort of thing.
So I have no idea when it occurred. I don't think I had OOo at all on 7.3;
which narrows it down to the installation of the beta or the upgrade to 8.0.
But I would swear the openoffice lines were not there when I originally created
and edited ~/.mailcap: I had a couple of lines for displaying images and one to
make the HTML viewer mutt.
So: if this was OpenOffice, I definitely consider it as a bug that it does so at
all without warning. If it is going to have the effrontery to decide that I want
to use it for everything and anything, it should flash up a little dialogue saying
that it is going to modify dotfiles.
I can understand it in /etc. But my personal dotfiles are -- well. Personal :)
And /etc/mailcap doesn't have it in there at all. Surely it should be there, not
in my dotfiles?
Fair play though: it at least augmented my .mailcap rather than overwriting it
But some kind of warning and "no, I like my geriatric .mailcap and will edit it
myself when I want to" option would be nice.
At the least, you can expect OpenOffice to edit the following dotfiles:
See the code in /usr/bin/ooffice. .sversionrc and .openoffice seem OK, since
they're owned by OpenOffice or something, but .mime.types is dubious --
especially since the user may already have entries for the defined mime-types.
OOo modifies mailcap as well.
The graphical installation program can certainly ask whether to edit
these files or not, but what should happen when the setup program is
run from the launcher script non-graphically and cannot receive user
input? It cannot put up a graphical dialog to ask, and it cannot
receive user input via the terminal. Since that's an important part
of the launch process, should your user installation be missing or
corrupted, I'm closing this as WONTFIX.
The entries should not be in /etc/mailcap because these are, well,
user settings. They are not system wide and a person who does not use
OOo probably would not want system-wide settings modified for no benefit.
Would a simple notice in documentation be appropriate with all this in
I see your point about non-GUI installation.
So yes, if it is going to do this, then a notice in the documentation
(which I promise to read :)) is ideal. If it says which specific files it
is likely to modify (like the FILES section some man pages have),
then I feel I know what's going on and that I can alter it back if
I want to.