Re: yum update Transaction Check Error
Hello thank you for, I removed subversion-1.4.2-4.el5.i386 and after had no problem anymore. I could make update and all was ok. Thank you for your answers Felix
updatedb or locate file
Hello After installing SL 5.3 x86_64, custom version I do not find the updatedb command and I'm unable to locate any file. Perhaps I missed to install this packages. I do not know where to find them I looked on fr.rpmfind.net but could not find any clue. Could you please tell me where do I find this packages to install them. Are there any new ones? Thank you Felix
Re: updatedb or locate file
Felix Farcas wrote: Hello After installing SL 5.3 x86_64, custom version I do not find the updatedb command and I'm unable to locate any file. Perhaps I missed to install this packages. I do not know where to find them I looked on fr.rpmfind.net but could not find any clue. Could you please tell me where do I find this packages to install them. Are there any new ones? Thank you Felix The locate command is at /usr/bin/locate and updatedb is at /usr/bin/updatedb Both are provided by the mlocate package. For future reference, 'yum whatprovides */locate' will help with such issues.
Re: trying to understand some dependencies
On Fri, 19 Jun 2009 10:27:15 -0500 Troy Dawson wrote: Hi Troy, [...] So the question is, who installed ati-fglrx and why... My guess puppet Why? Because puppet can work on generalities. You can say that you want the driver for your video card, and it can figure out the correct driver. Well, these are the packages (related to libGL) that I install with puppet: xorg-x11-devel.i386/x86_64 xorg-x11-Mesa-libGL.i386/x86_64 xorg-x11-Mesa-libGLU.i386/x86_4 they provide libGL, but those packages not explain (for me) why ati-fglrx is installed. Maybe, if they're not installed yet, yum solves dependency with ati-fglrx. does it make sense to you? [...] so, I understand that in order to get libGL.so.1 installed yum must install all packages listed in above output. Am I right? No, on this point you are wrong. The dependancy is libGL.so.1, and *any* of the provider packages can supply that package. It only has to install one of those packages. If your repositories were just plain SL, it would be xorg-x11-Mesa-libGL. But since you have (it looks like) sl-contrib and dag enabled, it can pick whichever one it feels is right. Ok, so now some questions about yum algorithm come to my mind: 1.-) Every time that yum has to install a package that needs libGL (for this example) does it try to install a package that provithes that library? or it only sees that libGL is already installled and install the desired package? 2.-) fist time that yum knows that needs libGL, how does it take the decission on which package from all that provides libGl has to install? for example: host A: package A needs libGl, it installs ati-glrx first and solves dependency, and later, puppet installs xorg-x11-Mesa-libGL that also solves the problem. host B: package A needs libGL but as xorg-x11-Mesa-libGL is already installed, it does not need ati-glrx. am I saying something senseless? any link to yum internal? thanks for your reply Troy. Troy Arnau
Missing file in perl-XML-SAX package
Hi, After installing perl-LDAP, the other dependency packages were installed: Jun 20 23:42:32 Installed: perl-XML-NamespaceSupport-1.09-1.2.1.noarch Jun 20 23:42:32 Installed: perl-XML-SAX-0.14-5.noarch Jun 20 23:42:33 Installed: 1:perl-LDAP-0.33-3.fc6.noarch Since then, one of my perl packages is doing strange things, and generating an error when run with: could not find ParserDetails.ini in /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX Checking the package: # rpm -ql perl-XML-SAX |grep ParserDetails /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini but the file doesn't actually exist on the filesystem: # ll /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini ls: /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini: No such file or directory I've un-installed and re-installed, same problem. The RPM DB says it's there when in fatc it's not. I'm using: Scientific Linux SL release 5.3 (Boron) Regards, Michael.
Re: Missing file in perl-XML-SAX package - SOLVED
Hi, After installing perl-LDAP, the other dependency packages were installed: Jun 20 23:42:32 Installed: perl-XML-NamespaceSupport-1.09-1.2.1.noarch Jun 20 23:42:32 Installed: perl-XML-SAX-0.14-5.noarch Jun 20 23:42:33 Installed: 1:perl-LDAP-0.33-3.fc6.noarch Since then, one of my perl packages is doing strange things, and generating an error when run with: could not find ParserDetails.ini in /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX Checking the package: # rpm -ql perl-XML-SAX |grep ParserDetails /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini but the file doesn't actually exist on the filesystem: # ll /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini ls: /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX/ParserDetails.ini: No such file or directory I've un-installed and re-installed, same problem. The RPM DB says it's there when in fatc it's not. I found this: http://perl-xml.sourceforge.net/faq/ which in this section: 3.18. could not find ParserDetails.ini Explains the following: If you are packaging XML::SAX in an alternative distribution format (such as RPM), your post-install script should check if ParserDetails.ini exists and if it doesn't, run this command: perl -MXML::SAX -e XML::SAX-add_parser(q(XML::SAX::PurePerl))-save_parsers() Don't unconditionally run this command, or users who re-install XML::SAX may find that any fast SAX parser they have installed will be replaced as the default by the pure-Perl parser. So this tells us that the post-install script in the RPM doesn't actually work right? I ran that perl command above and the ParserDetail.ini file was then created and the problem went away. Should the issue with this RPM package be raised in bugzilla? Regards, Michael. I'm using: Scientific Linux SL release 5.3 (Boron) Regards, Michael. --- End of Original Message ---
