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 ---
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: 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
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.
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: 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
