[arch-general] First Problem with pacman - Need to understand why

[Aaron Griffin]

On Wed, Apr 22, 2009 at 2:45 PM, David C. Rankin
<drankinatty at suddenlinkmail.com> wrote:
> checking package integrity...
> (12/12) checking for file conflicts
> [#############################################] 100%
> error: could not prepare transaction
> error: failed to commit transaction (conflicting files)
> ttf-dejavu: /usr/share/fonts/TTF/DejaVuSans-Bold.ttf exists in filesystem
> ttf-dejavu: /usr/share/fonts/TTF/DejaVuSans-BoldOblique.ttf exists in filesystem
> ttf-dejavu: /usr/share/fonts/TTF/DejaVuSans-ExtraLight.ttf exists in filesystem
>        <snip - remaining dejavu variants>
> Errors occurred, no packages were upgraded.
>
>        And "Yes", DejaVu fonts did exist in /usr/share/fonts/TTF softlinked to
> /usr/share/fonts/truetype, but why does pacman care? If the same font already
> exists in a directory, that shouldn't cause the install to blow up -- should it?

pacman cares because pacman will try it's hardest to never ever break
your system unless you say so. If pacman has no knowledge of files in
your system, it'd be amazingly stupid to blindly overwrite them. What
happens if I wrote a big long OOo document and saved it (stupidly) as
/usr/bin/mydoc and then pacman decided to install an app named
"mydoc". Poof, lost my work.

I know the above is a contrived example, but it serves to illustrate
the point: pacman is not in control of your system. You are. Pacman
will never say "I know better than you, so I'll just replace this with
what I think it should be". Instead it will say "woah woah woah... you
did something I don't understand. You deal with it and tell me when
you figured it out"