[suggest] perl-Apache-ASP RPM
nkadel at gmail.com
Fri Jun 29 10:07:24 CEST 2007
Michael Mansour wrote:
> Hi Nico,
>> Michael Mansour wrote:
>>> Hi Dag,
>>> Can you help with any of the below?
>>> I really do need the perl-Apache-ASP installed just don't know the way forward
>>> at the point since receiving the dependency problem below.
>>> Thanks. Appreciate any advice/help.
>> Oh, I believe you.
>>>>> I've checked using the "yum --enablerepo=rpmforge list extras" (nice
>>>>> feature), and the only perl modules I get which are extra are:
>>>>> perl-DBI.noarch 1.50-2 installed
>>>>> perl-Filesys-Df.noarch 0.90-1 installed
>>>>> perl-HTML-Parser.i386 3.56-1 installed
>>>>> perl-Math-BigInt.noarch 1.86-1 installed
>>>>> perl-Math-BigRat.noarch 0.19-1 installed
>>>>> perl-Sys-Syslog.noarch 0.18-1 installed
>>>>> perl-Test-Simple.noarch 0.70-1 installed
>>>>> perl-Time-HiRes.noarch 1.9707-1 installed
>>>>> perl-bignum.noarch 0.21-1 installed
>> Hmm. This could be your issue: if you install and grab packages
>> from alternat repositories, you can seriously screw up the
>> dependency chains. Where did these packages come from? And do you
> The packages above come from MailScanner (www.mailscanner.info), which I use
> for scanning email. They aren't provided in a repo, since when installing
> MailScanner it comes with src.rpm versions, and then you run install.sh and
> that script goes through and recompiles the src.rpm's to binary rpm's and
> installs them on the system.
> The way the MailScanner install.sh script works is, if it finds the perl
> modules already installed (from rpmforge f.e.) then it skips the src.rpm
> recompiles and accepts the fact that the perl module is installed on the OS
> and moves on in the install script.
OK. That's begging for issues. Yank them back out, do the
perl-Apache-ASPX install, then recompile those add-ons, I think. It
looks like you've run into some version skew issues: this MailScanner
software has effectively created its own, *special* little repository
that no one else has a chance to cross-compile against. It's a common
approach in the Gentoo world, and other "just compile it when you need
it" worlds, but this is precisely the sort of compatibility issue that
can result. Fortunately, RPM at least reports the incompatibility before
you start randomly installing new packages and breaking old dependencies.
> I install many of the perl RPM's needed for MailScanner from rpmforge,
> unfortunately even though I wish rpmforge carried the RPM's above, it doesn't
> so MailScanner can't function with them.
Do you have some decent public FTP or HTTP space that you can compile
and publish the SRPM's for RPMforge to pick them up, and include them
for the future? Even if you don't, it's useful to put such RPM's and
SRPM's in their own local repository for use across multiple platforms,
rather than compiling them on the fly.
> I could try removing the RPM's above and temporarily disabling MailScanner if
> you think this will make a difference to pulling down all the necessary
> perl-Apache-ASP RPMs?
>> have a "dag" repository, or a "rpmforge" repoitory. And have you
> I have both (as of earlier in our discussions when trouble-shooting), as
> supplied by SL:
> # cat dag.repo
> name=DAG rpms
> and as supplied by the rpmforge-release RPM:
Got it. Is this repository the same as RPMforge's? Or is it tweaked by
the Scientific Linux managers for their environment? If it is, you
should just use the dag one for consistency, and it's probably
> # cat rpmforge.repo
> # Name: RPMforge RPM Repository for Red Hat Enterprise 4 - dag
> # URL: http://rpmforge.net/
> name = Red Hat Enterprise $releasever - RPMforge.net - dag
> #baseurl = http://apt.sw.be/redhat/el4/en/$basearch/dag
> mirrorlist = http://apt.sw.be/redhat/el4/en/mirrors-rpmforge
> #mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
> enabled = 0
> protect = 0
> gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
> gpgcheck = 1
> Enabling the rpmforge repo with an install of perl-Apache-ASP produced the
> same problem as we've been discussing.
Fair enough. I suspect they match in contents.
>> done a "yum update --enablerepo=rpmforge" or "yum update --
>> enablerepo=dag" lately? I'm wondering if you've run into some sort
>> of version skew between required packages, and out of date ones.
> I haven't done that know, but checking what would be installed:
> # yum --enablerepo=rpmforge check-update
> Loading "kernel-module" plugin
> Setting up repositories
> rpmforge 100% |=========================| 1.1 kB 00:00
> Reading repository metadata in from local files
> primary.xml.gz 100% |=========================| 1.5 MB 00:19
> rpmforge : ################################################## 6470/6470
> Added 20 new packages, deleted 0 old in 16.89 seconds
> apt.i386 0.5.15lorg3.2-1.el4.rf rpmforge
> ipw2200-firmware.noarch 3.0-3.nodist.rf rpmforge
> kernel.i686 2.6.9-55.0.2.EL sl-errata
> kernel-devel.i686 2.6.9-55.0.2.EL sl-errata
> kernel-utils.i386 1:2.4-13.1.99 sl-base
> lftp.i386 3.5.10-1.el4.rf rpmforge
> memtest86+.i386 1.70-1.el4.rf rpmforge
> mtr.i386 2:0.72-1.el4.rf rpmforge
> perl-Filesys-Df.i386 0.92-1.el4.rf rpmforge
> python-elementtree.i386 1.2.6-7.el4.rf rpmforge
> sqlite-devel.i386 3.1.2-3 sl-base
> syslinux.i386 3.51-1.el4.rf rpmforge
> xrestop.i386 0.4-1.el4.rf rpmforge
> So there's not really much there supplied by rpmforge which would seem to
> effect that.
> Your comments and suggestions are appreciated Nico.
OK, use either the dag or the rpmforge repo, not both. Then run "yum
update" for the non kernel packages at least, I think, especially that
perl-Filesys-Df. And check whether the dag repository you use, and the
rpmforge repository, are identical. If not, use the dag one.
More information about the users