On 07/08/2009 08:05 AM, [email protected] wrote:
Hugo van der Kooij wrote:
Joe Ogulin wrote:
I am running CentOS 5.3. I thought it was just going to be two packages...
perl-MP3-Tag and perl-Unix-Process... then today, it added 5 more.
When I go to look for the dependencies, I am lucky if I can find one for
Fedora 11,
and even if I do find that one, it won't install because of other
dependency problems.
As an example, I found perl-Exception-Class-1.29.1 ... but it was for
PLD, not CentOS.
When I restrict the search to be for CentOS/RHEL, the most recent
version I find is
1.24... from the rpmforge repository! I can find the
perl(IPC::System::Simple) dependency,
but it's for Fedora 11, and to install that one on CentOS 5.3 has all
kinds of other
dependency issues that cannot be resolved easily.
Great. So you mix Centos, rpmforge and random other packages and now all
of a sudden it is a rpmforge problem?
Please make sure that you only combine Centos and rpmforge repositories
before you start to report problems.
There is little point in trying to resolve dependency issues caused by
other repositories or manually installed packages.
Geez, did you ever miss the mark. The CentOS repository is going to be the
base OS repository and you have absolutely no choice in using it, if you want
an up to date OS package.
As for other stuff, I was referring to the stuff on the website that says,
"Try to look for a solution before saying there's a bug." Hey, that sounds
like a great idea. I'll go see if I can find the necessary packages elsewhere
before filing a bug. So I go look... and can't find anything. Therefore, this
is a bug.
These problems are showing up on my development box. I need to keep these
things
installed as I handle systems development, integration, and administration... so
when other developers need packages for various perl modules, I can go get them
and install them with confidence.
All I asked was that you please do not just put a new version into the "release"
repo without testing its dependencies first. Someone else suggested, and I
fully
agree, that you need an rpmforge-testing repo... where there is no absolute
guarantee
that what is contained in there will work and you install those packages at your
own risk. Stuff in a "release" or "updates" repo should at least be able to
resolve
with what's there.
If I had the time, I *would* work on a package or two. I've done that in the
past,
but primarily when the packages I was working on directly affected work.
Unfortunately,
the ones that I found that have broken dependencies are not necessary ones for
my work so they don't get a high priority in the work queue.
If you guys had bugzilla or some other bug reporting system running, I would've
filed
bugs there for each of the broken packages instead of putting it on this list.
Joe
--
"Those who would give up freedom for security deserve neither." B. Franklin
Joe Ogulin [email protected]
This message is made of 100% recycled electrons.
Disclaimer: I'm responsible for the content of this message. Nobody else is.
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
