[arch-general] First Problem with pacman - Need to understand why
Listmates, I ran into my first problem with pacman and, I know what caused the problem, but I need to understand why pacman thought it was a problem to begin with. Here is the situation: Trying to start X, and one complaint was no /usr/share/fonts/TTF directory. I had a /usr/share/fonts/truetype directory so I just softlinked the missing TTF to truetype to get rid to the error on startx. startx liked the solution. Then I went to install audio-convert which noted additional dependencies of (blah.. blah.. mplayer), so I we to install the optional dependencies: **pms below is just aliased to 'pacman -Sy' [14:15 archangel:/home/david] # pms lame id3lib vorbis-tools flac faac faad2 musepack-tools mplayer <snip> 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? Well, since I cause the problem with the softlink, fixing it was pretty easy, but what I'm curious about is why it was a problem to begin with. I want to understand what the rules are for pacman so I don't cause any additional problems in the future with softlinks (which I use in moderation, but do use). So any body got quick explanation or quick link so I can figure out what not to do again?? Thanks -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
David C. Rankin wrote:
Listmates,
I ran into my first problem with pacman and, I know what caused the problem, but I need to understand why pacman thought it was a problem to begin with. Here is the situation:
Trying to start X, and one complaint was no /usr/share/fonts/TTF directory. I had a /usr/share/fonts/truetype directory so I just softlinked the missing TTF to truetype to get rid to the error on startx.
Generally a bad idea to do things like that ...
**pms below is just aliased to 'pacman -Sy'
[14:15 archangel:/home/david] # pms lame id3lib vorbis-tools flac faac faad2 musepack-tools mplayer
<snip>
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 pacman rightly complained.
Well, since I cause the problem with the softlink, fixing it was pretty easy, but what I'm curious about is why it was a problem to begin with.
Because you added a system file manually.
I want to understand what the rules are for pacman so I don't cause any additional problems in the future with softlinks (which I use in moderation, but do use). So any body got quick explanation or quick link so I can figure out what not to do again??
Thanks
You should generally let pacman take care of creating/removing all of your system files for you. If you start creating system files that it doesn't know about (or deleting ones), you're bound to hit problems when you add new packages, upgrade packages, etc. Generally a good rule of thumb IMO is that you can edit /etc/ config files, but shouldn't add things. (Exceptions maybe would include things like creating backup files - i.e., cp /etc/foo /etc/foo~) So, backing up, why did X give you the "no /usr/share/fonts/TTF directory" error? I'm not sure exactly. Obviously you had no TTF font packages installed (e.g., ttf-dejavu, ttf-ms-fonts, ttf-liberation, etc.) but I didn't think X needed one of them - or the presence of the /usr/share/fonts/TTF directory - in order to start. Are you missing any key xorg packages? i.e., xorg-server, xorg-font-utils, xorg-fonts-alias, xorg-fonts-encodings, xorg-fonts-misc. Maybe do a "pacman -Q | grep xorg" and see? Of course, the obvious workaround here is to just install one of the TTF font packages, but you probably still should find out why X barfed and/or what packages you might be missing, as you might run into trouble down the road otherwise. Might be worth flipping through the Arch Xorg wiki page a bit too: http://wiki.archlinux.org/index.php/Xorg One other thing: not sure why you have a /usr/share/fonts/truetype directory in the first place. I don't have one. Why is that there and where did it come from? Did you install that manually and/or is it a left over from a previous distro? Do a "pacman -Qo /usr/share/fonts/truetype/DejaVuSans-Bold.ttf" and see which package owns it. HTH, DR
On Wed, Apr 22, 2009 at 2:45 PM, David C. Rankin <drankinatty@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"
On Wed, Apr 22, 2009 at 6:02 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
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"
These two paragraphs are great, Aaron! Would you mind if I add them to the wiki page of Pacman regarding the "something: something exists in filesystem" error, or is it too much informality for the wiki? -- Malformed message exception
On Wed, Apr 22, 2009 at 5:37 PM, Guilherme M. Nogueira <g.maionogueira@gmail.com> wrote:
On Wed, Apr 22, 2009 at 6:02 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
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"
These two paragraphs are great, Aaron! Would you mind if I add them to the wiki page of Pacman regarding the "something: something exists in filesystem" error, or is it too much informality for the wiki?
Feel free to do what you want. All my mails are licensed under the WTFPL[1] 1: http://sam.zoy.org/wtfpl/COPYING
So this explains the reporter mishaps perfectly then. They take your e-mails, freely change them, and then write their articles :) -Andrei Thorp On Thu, Apr 23, 2009 at 8:11 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Apr 22, 2009 at 5:37 PM, Guilherme M. Nogueira <g.maionogueira@gmail.com> wrote:
On Wed, Apr 22, 2009 at 6:02 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
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"
These two paragraphs are great, Aaron! Would you mind if I add them to the wiki page of Pacman regarding the "something: something exists in filesystem" error, or is it too much informality for the wiki?
Feel free to do what you want. All my mails are licensed under the WTFPL[1]
Aaron Griffin wrote:
On Wed, Apr 22, 2009 at 2:45 PM, David C. Rankin <drankinatty@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"
That really was a really good "contrived" example, but it makes sense. pacman is coded to be conservative and doesn't have and way of checking whether what it is overwriting is a font file or something else and since it isn't a config file there isn't a md5 hash comparison done to determine whether to overwrite or install as .pacnew. So in this case pacman just balked at installing the font, issued the warnings and quit. Now I (at least think I) understand. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Op Wed, 22 Apr 2009 14:45:10 -0500 schreef "David C. Rankin" <drankinatty@suddenlinkmail.com>: <SNIP>
no /usr/share/fonts/TTF directory. I had a /usr/share/fonts/truetype directory so I just softlinked the missing TTF to truetype to get rid to the error on startx. startx liked the solution.
Softlinking is just patching the system without solving the underlying problem - it should be discouraged. Why that directory wasn't there is because you didn't have any TTF fonts at that time. Why the other dir was there, is probably due to some leftovers or maybe a package (from AUR?) that didn't extract the fonts in the right place? I don't know. I do know that X defines the FontPath in xorg.conf, so if startx complained, you could simply change the FontPath in /etx/X11/xorg.conf. And IIRC, the app 'fontconfig' can do ao this for you. Vincent -- Advocatenkantoor Suy, Van Baeveghem & Van Houtte Brusselsestraat 108 9200 Dendermonde T +32.52.52.06.05 F +32.52.52.06.46 W http://www.synergylaw.be
Vincent Van Houtte wrote:
Op Wed, 22 Apr 2009 14:45:10 -0500 schreef "David C. Rankin" <drankinatty@suddenlinkmail.com>: <SNIP>
no /usr/share/fonts/TTF directory. I had a /usr/share/fonts/truetype directory so I just softlinked the missing TTF to truetype to get rid to the error on startx. startx liked the solution.
Softlinking is just patching the system without solving the underlying problem - it should be discouraged.
Why that directory wasn't there is because you didn't have any TTF fonts at that time. Why the other dir was there, is probably due to some leftovers or maybe a package (from AUR?) that didn't extract the fonts in the right place? I don't know.
No, that's my fault too. I liked my true type fonts, so I brought them with me for the Arch Linux install;-) I just mounted the opensuse install which resides on /dev/mapper/nvidia_fdaacfde to /mnt/suse and copied my truetype directory over.
I do know that X defines the FontPath in xorg.conf, so if startx complained, you could simply change the FontPath in /etx/X11/xorg.conf. And IIRC, the app 'fontconfig' can do ao this for you.
Vincent
That was the strange part. Somewhere Arch is setting /usr/share/fonts/TTF as a default directory to load on X startup. My files section looked like this when X was complaining about no /usr/share/fonts/TTF: Section "Files" FontPath "/usr/share/fonts/misc:unscaled" FontPath "/usr/share/fonts/75dpi:unscaled" FontPath "/usr/share/fonts/100dpi:unscaled" FontPath "/usr/share/fonts/Type1" FontPath "/usr/share/fonts/URW" # FontPath "/usr/share/fonts/Speedo" FontPath "/usr/share/fonts/cyrillic" FontPath "/usr/share/fonts/truetype" FontPath "/usr/share/fonts/uni:unscaled" FontPath "/opt/kde/share/fonts" FontPath "/usr/local/share/fonts" InputDevices "/dev/gpmdata" InputDevices "/dev/input/mice" EndSection Dunno? Right now I'm using the default xorg.conf generated by nvidia-xconfig with only my old monitor definition cut and pasted in. (though from looking at Xorg.0.log it wasn't necessary because the EDID info was recognized) The default xorg.conf contains no font path information, so I presume the startup just parses /usr/share/fonts for all dirs with mkfontdir information available. Right now, I'm just tickled to be up and running with kde3 and I'm working out the details to make the config permanent. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (6)
-
Aaron Griffin
-
Andrei Thorp
-
David C. Rankin
-
David Rosenstrauch
-
Guilherme M. Nogueira
-
Vincent Van Houtte