Hi,
I'm using CentOS 4.3 on all my PC's, and I'm very happy with it. Everything *just* works.
I want to give DVD::RIP 0.97.10 a try. I enabled rpmforge and kbs repos, but there's only 0.52.2 available, which has an annoying bug in it. So I installed the main dependency, transcode, via yum. Then I downloaded the (PERL) sources of DVD::RIP 0.97.10, ran configure (e. g. perl Makefile.PL), and it complains about the following missing PERL modules:
AnyEvent 1.02 Event::ExecFlow 0.61 Event::RPC 0.89 Gtk2 1.081 Gtk2::Ex::FormFactory 0.62 Locale::TextDomain 0 [sic!]
Next step was to hunt these down with yum. Alas, yum install perl- AnyEvent return a missing dependency error (Coro::Signals) and says it won't be installed.
Each of these modules has quite an impressive list of dependencies in return. Now I already performed a manual install of these on Slackware, and it ran fine. So I gave it a try here. Following a suggestion on IRC, I used cpan2rpm for this. But I couldn't get past the second module.
The first two dependencies are ExtUtils::Depends and ExtUtils::PkgConfig. Now I can install *one* of these fine with cpan2rpm, but when I get to the second module, I can't rpm -ivh it, because RPM complains about a clash with the other module.
Which leaves me clueless. Any suggestions?
Niki Kovacs
Hi Niki,
Niki Kovacs wrote:
Next step was to hunt these down with yum. Alas, yum install perl- AnyEvent return a missing dependency error (Coro::Signals) and says it won't be installed.
Each of these modules has quite an impressive list of dependencies in return. Now I already performed a manual install of these on Slackware, and it ran fine. So I gave it a try here. Following a suggestion on IRC, I used cpan2rpm for this. But I couldn't get past the second module.
The first two dependencies are ExtUtils::Depends and ExtUtils::PkgConfig. Now I can install *one* of these fine with cpan2rpm, but when I get to the second module, I can't rpm -ivh it, because RPM complains about a clash with the other module.
Which leaves me clueless. Any suggestions?
It seems you want to stick with rpm, but it you are willing to try perl's own "package installer" -- CPAN -- , you should be able to do this with no problems after some initial config.
To run CPAN,
$ perl -MCPAN -e shell
It'll ask you a bunch of config questions to set up for your environment. You can typically accept the default. Say you want to be asked before installing dependies. Choose a mirror or 2 or 3 near you when that choice comes up. Then, when that is done...
cpan> install DVD::RIP
It'll find all the cascading dependencies and install them for you after asking. You might get some install errors due to compile problems or test errors. Watch for them and, if they happen, try to install that package alone and fix the errors.
I've been using this for years and been very happy with it. I understand there are other, newer installers for perl as well.
Take care,
Kurt Hansen
It seems you want to stick with rpm, but it you are willing to try perl's own "package installer" -- CPAN -- , you should be able to do this with no problems after some initial config.
Sticking with rpm should be the preference when using rpm based systems. It is understood that in some cases it may not be possible. CPAN comes with its own risks. For example, anything installed via cpan won't show up in rpm, so other rpms won't know that it's there. CPAN may also attempt to update parts of perl already on your system, which can lead to instability or other unexpected bahavior. In short, CPAN should be a last resort. It should be used carefully and sparingly, and watched like a hawk for attempted funky behavior.
Jim Perrin wrote:
It seems you want to stick with rpm, but it you are willing to try perl's own "package installer" -- CPAN -- , you should be able to do this with no problems after some initial config.
Sticking with rpm should be the preference when using rpm based systems. It is understood that in some cases it may not be possible. CPAN comes with its own risks. For example, anything installed via cpan won't show up in rpm, so other rpms won't know that it's there. CPAN may also attempt to update parts of perl already on your system, which can lead to instability or other unexpected bahavior. In short, CPAN should be a last resort. It should be used carefully and sparingly, and watched like a hawk for attempted funky behavior.
My experience is that I have to watch rpm installed stuff "like a hawk for attempted funky behavior." :-)
It may be my own personal experience, but I've found CPAN easier to control and watch than yum or up2date.
Furthermore, for the stuff I do -- primarily Apache/mod_perl -- I've found the rpms coming out of Red Hat a day late and a dollar short. Either well behind mod_perl development or the perl not optimized for mod_perl. (In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS.) Plus, I've found it easier to understand what is going by using CPAN or compiling from source for these items.
But, this also could be inertia on my part. :-) CPAN was the easier option when I got started on this a few years back.
Take care,
Kurt
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
Do you have any experience with the rpms to which I'm referring? Do you work with the same software I do?
Regards,
Kurt Hansen
On Thu, 2006-06-01 at 17:17 -0400, Kurt Hansen wrote:
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
You choose not to use RHEL / CentOS, yet you are giving expert advice.
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
Do you have any experience with the rpms to which I'm referring? Do you work with the same software I do?
Jim Perrin is a CentOS admin ... so I would say he has a little bit of experience with this issue ... YES :)
Installing perl modules from CPAN absolute worst possible solution and should be used only as the absolute last resort.
Or, maybe you know more about this distro that the people who make it?
On Thu, 2006-06-01 at 17:18 -0500, Johnny Hughes wrote:
Installing perl modules from CPAN absolute worst possible solution and should be used only as the absolute last resort.
Or, maybe you know more about this distro that the people who make it?
He's not saying that the stock perl modules packaged for the disto are bad for the distro itself. He means that they no longer are current and won't support current applications. Mod_perl is a good example. There is a big difference between what RHEL/Centos bundles and the current version. It's a typical conflict between the stability goals for the disto and usability in terms of up to data applications and I'm not sure there is a good answer.
Johnny Hughes wrote:
On Thu, 2006-06-01 at 17:17 -0400, Kurt Hansen wrote:
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
You choose not to use RHEL / CentOS, yet you are giving expert advice.
No, I use CentOS. I don't use RHEL.
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
Do you have any experience with the rpms to which I'm referring? Do you work with the same software I do?
Jim Perrin is a CentOS admin ... so I would say he has a little bit of experience with this issue ... YES :)
Installing perl modules from CPAN absolute worst possible solution and should be used only as the absolute last resort.
Or, maybe you know more about this distro that the people who make it?
It appears that I know more about mod_perl than the people who make CentOS or the RH distributions.
Look, I just started using CentOS a few months back. I try to make a helpful suggestion, to take some of the load off other people, for the first time, and I get insulted.
Is that how you get people to help out on this project?
The people who have direct experience with using perl on this thread have seemed to support my view.
Plus, it appears only the folks with perl experience are the ones who are actually trying to answer the original poster's question. Neither you nor Jim Perrin have provided an answer that can solve his problem.
Regards,
Kurt Hansen
On Thu, 1 Jun 2006, Johnny Hughes wrote:
Installing perl modules from CPAN absolute worst possible solution and should be used only as the absolute last resort.
When I get to the point that I absolutely must have a CPAN module that conflicts with or requires extensive tweaking of the system Perl installation, I fall back on the virtue of laziness. :-)
For me, that means building Perl into its own tree (/usr/local/perl5 or somesuch) and using CPAN to manage it. Scripts using that perl begin #!/usr/local/perl5/bin/perl and are therefore easy to identify. It's also easy to tar up (or wrap with rpm) that directory tree for installation on multiple systems.
The same is true for any scripting language that ships with a distribution. There are too many system tools that require stable scripting environments to go messing with them.
That's not to say that you can't do lots of rpm-based installations into the system Perl tree. It's just that I find it faster -- and safer -- to roll my own...
On Thu, 1 Jun 2006, Paul Heinlein wrote:
On Thu, 1 Jun 2006, Johnny Hughes wrote:
Installing perl modules from CPAN absolute worst possible solution and should be used only as the absolute last resort.
When I get to the point that I absolutely must have a CPAN module that conflicts with or requires extensive tweaking of the system Perl installation, I fall back on the virtue of laziness. :-)
In light of all this (but unrelated) it may be nice to know that we've recently stopped providing perl-CPANPLUS and perl-Extutils-AutoInstaller from the repositories because of 2 reasons:
+ No package should rely on it (I fixed the ones that have been committed with it as BuildRequires, ugh...)
+ No person in his right mind should install it, let alone manually. If someone wants to break his set of dependencies on his system, make him suffer to get there. (That's not really the intent, but still we should avoid it happening accidentally)
It is so easy to create your own CPAN packages that there really should be no reason why you could not package it yourself.
If you require specific versions and you have trouble building them based on one of our SPEC files, let us know on packagers@lists.rpmforge.net.
If you require a CPAN module that is not yet available from RPMforge, request it from suggest@lists.rpmforge.net
And if you have some spare time because all the CPAN package are already available, think about helping others with their request for packages.
I'd like to have a better procedure to build packages, but if you're somewhat technical you should get far by simply taking:
perl-Apache-ASP.spec (for arch perl packages) or perl-Compress-Zlib.spec (for noarch perl packages)
then change by hand what is necessary. (look at the SPAN site for most of the meta-information). Then try to rebuild it using:
rpmbuild -bb <spec-file>
And if it generates a package and it can be installed. Send the SPEC file to the suggest@lists.rpmforge.net.
Dries has been doing a lot of work to provide as much as possible, but we may not know where we can best spend our efforts.
PS There is a good reason to use these SPEC files as a basis instead of using one of the auto-generating tools. We provide perl packages for a wide range of distributions from a single SPEC file.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On 6/1/06, Kurt Hansen khansen@charityweb.net wrote:
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
Actually, I was questioning the validity of that statement since RHEL and centos are built from identical sources. Theoretically you should have the same problem with CentOS that you do with RHEL. If something is different, I'm sure the other admins would be interested in hearing about it as well, since we are trying to be as compatible with RHEL as possible. Forgive me for trying to work a little humor (at your expense) into the day.
As others have pointed out mod_perl has been kindly supplied via a 3rd party repository, and I do agree that in very rare instances cpan is useful. However, for rpmbased distributions, as much software as humanly possible should be installed via rpm. This allows for easier administration, software auditing, replication and portability of packages, and in the event of failure.... blame, since the packages tell you who built them and when.
As others in this thread pointed out, CPAN is a moving target and poses a level of risk as such. Packages installed via rpm (while maybe not perfect) do not suffer from this affliction, are portable, predictable, and can be identically duplicated across as many machines as needed, even months down the road. The entire original meaning of my post was to be careful, and only use cpan as a last resort on rpm based systems. That point stands.
Jim Perrin wrote:
On 6/1/06, Kurt Hansen khansen@charityweb.net wrote:
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
Actually, I was questioning the validity of that statement since RHEL and centos are built from identical sources. Theoretically you should have the same problem with CentOS that you do with RHEL. If something is different, I'm sure the other admins would be interested in hearing about it as well, since we are trying to be as compatible with RHEL as possible. Forgive me for trying to work a little humor (at your expense) into the day.
Forgiven, of course.
Let me explain further -- to use RHEL, I'd have to pay thousands per year for support. However, for the components that are most critical for my application, perl and mod_perl, I have found that the rpms from Red Hat have been defective or non-optimal. This wasn't just a one-time thing, but happened several times from RH7.X on up through FC2. This proved to me that Red Hat was unable to support the components of their system that were most critical to me. In each installation for the past couple of years, I've built an installed my own perl and mod_perl. I was also concerned that Red Hat would balk at supporting other parts of my systems if I had deviated from the supplied software. So, it didn't seem I would be getting any value for my thousands.
I first went with Fedora Core, but realized over time that FC is the old rawhide. So, I've switched to CentOS on more recent systems. I roll my own perl, mod_perl, Apache, and install perl modules thru CPAN and have been doing so for the past 4 years since RH7.X. It's worked well so have stuck with it.
I think Les Mikesell and Paul Heinlein later in this thread do a good job of explaining the challenges and solutions of mod_perl on RH-based systems.
As others have pointed out mod_perl has been kindly supplied via a 3rd party repository, and I do agree that in very rare instances cpan is useful. However, for rpmbased distributions, as much software as humanly possible should be installed via rpm. This allows for easier administration, software auditing, replication and portability of packages, and in the event of failure.... blame, since the packages tell you who built them and when.
As others in this thread pointed out, CPAN is a moving target and poses a level of risk as such. Packages installed via rpm (while maybe not perfect) do not suffer from this affliction, are portable, predictable, and can be identically duplicated across as many machines as needed, even months down the road. The entire original meaning of my post was to be careful, and only use cpan as a last resort on rpm based systems. That point stands.
I understand your point. Note Paul Heinlein's "laziness" comment later in this thread, and my inertia one in my original comment.
I'd have to create my own SRPM's to use rpm for my own rolled solutions, correct? That would make maintainance of my system easier, correct? These are honest questions, but I just haven't had the time to learn how to build SRPMs given that all is working well for me now.
Take care,
Kurt
I understand your point. Note Paul Heinlein's "laziness" comment later in this thread, and my inertia one in my original comment.
Ah the eternal motivator... or something like that...
I'd have to create my own SRPM's to use rpm for my own rolled solutions, correct?
While I haven't done this with perl specifically ( I don't do much perl work, so I suppose my ivory tower preaching here might be considered hypocritical) many times you can simply modify an existing srpm to use a new prefix value and install to /opt/ (/usr/local/ being for source builds, which I discourage and avoid). In the event that a new srpm needs to be created, it's really not that difficult most of the time, as it's essentially creating a text file which does the basic ./configure/make/make install for you. There are a load of tutorials out there to walk you through this, and the folks in #rpm on freenode (irc) are quite helpful generally.
That would make maintainance of my system easier, correct?
It would allow you to produce a reliable build that you can duplicate later if you need to, with more book-keeping information than is available in a source build. If you return to cpan 3 months down the road, your module or a dependency may have been altered, and you won't necessarily have the same build across your systems. If you haven't noticed, I'm anal about consistency. The rpm will also tell you when something was built, who built it, what the build system was, all the files included in the build and most things about them, permissions, checksums and more so you know if anything has been changed.
These are honest questions, but I just haven't had the time to learn how to build SRPMs given that all is working well for me now.
If what you have is working for you, there's no need to abruptly change. Srpm construction can always help if you're working with an rpm based distro so if you have a free minute it is worth learning.
Even if people don't always practice them, in my opinion they should preach the good habits and know them. I find one of the things that tends to hold people back is the assorted collection of bad habits they tend to pick up and pass on when trying to get something working. We've all done things the quick and dirty way, but there's no benefit to passing those methods on to others. I tend to get irritable and confrontational when I see people advocating what I consider to be sloppy computing, because the people they're assisting may not recognize it as a patch, hack or otherwise sloppy behavior. I will correct people when I see this, and I fully expect people to correct me if they see me doing it.
/Yes I like my ivory tower. Why do you ask? :-P
On Thu, 2006-06-01 at 21:04 -0400, Kurt Hansen wrote:
This wasn't just a one-time thing, but happened several times from RH7.X on up through FC2. This proved to me that Red Hat was unable to support the components of their system that were most critical to me.
These are products from the "consumer line" of the upstream vendor. For a fair judgment of their products, it is better to look at their enterprise offerings. Besides that my experience is that they are very willing to fix bugs if you send good bug reports and/or patches. So, did you try an enterprise version, and if so, did you raise these issues to the upstream vendor?
I was also concerned that Red Hat would balk at supporting other parts of my systems if I had deviated from the supplied software. So, it didn't seem I would be getting any value for my thousands.
Yeah. If you don't require the support, it is a shame to waste that money.
-- Daniel
On Fri, 2006-06-02 at 03:19, Daniel de Kok wrote:
On Thu, 2006-06-01 at 21:04 -0400, Kurt Hansen wrote:
This wasn't just a one-time thing, but happened several times from RH7.X on up through FC2. This proved to me that Red Hat was unable to support the components of their system that were most critical to me.
These are products from the "consumer line" of the upstream vendor. For a fair judgment of their products, it is better to look at their enterprise offerings.
I think you are missing the point that there was one version of mod_perl 1.x shipped as an update to RH7.3 that was actually usable. It was broken again in RH8 and subsequent versions including went into RHEL 3 and 4. I think the 2.x version may finally be usable again in FC5 but I haven't really done stress testing.
Besides that my experience is that they are very willing to fix bugs if you send good bug reports and/or patches. So, did you try an enterprise version, and if so, did you raise these issues to the upstream vendor?
The problem is that the 1.99x versions of mod_perl included in the EL distros (and thus Centos) wasn't really release versions and thus even if built properly aren't suitable for current applications. The 'upstream vendor' has a policy against making behavior-changing updates so when you need a change like this you are out of luck.
I was also concerned that Red Hat would balk at supporting other parts of my systems if I had deviated from the supplied software. So, it didn't seem I would be getting any value for my thousands.
Yeah. If you don't require the support, it is a shame to waste that money.
Centos is the answer to a lot of problems. Just not this one unless someone were to say, rebuild the fedora FC5 versions of apache, perl, and mod_perl under Centos and put it in a yum repository somewhere in a way that updates would push through for people who want them.
On Fri, 2 Jun 2006, Les Mikesell wrote:
On Fri, 2006-06-02 at 03:19, Daniel de Kok wrote:
On Thu, 2006-06-01 at 21:04 -0400, Kurt Hansen wrote:
I was also concerned that Red Hat would balk at supporting other parts of my systems if I had deviated from the supplied software. So, it didn't seem I would be getting any value for my thousands.
Yeah. If you don't require the support, it is a shame to waste that money.
Centos is the answer to a lot of problems. Just not this one unless someone were to say, rebuild the fedora FC5 versions of apache, perl, and mod_perl under Centos and put it in a yum repository somewhere in a way that updates would push through for people who want them.
Exactly, and I think we have to 'evolve' from a set of fixed repositories (in CentOS or RPMforge) to a dynamic range of 'appliance' repositories that build on top of the base OS and can be used next to the official repositories.
They may replace (update) core packages or fix things that are known to be broken to many people. If CentOS (wiki?) is able to funnel and manage something like this, I'm sure lots of the same cause-inflicted pain can be transformed into a community of appliance repositories.
If only there would be a good RPM build tool that provide conformance testing with simplicity.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Fri, 2006-06-02 at 15:21 +0200, Dag Wieers wrote:
Exactly, and I think we have to 'evolve' from a set of fixed repositories (in CentOS or RPMforge) to a dynamic range of 'appliance' repositories that build on top of the base OS and can be used next to the official repositories.
They may replace (update) core packages or fix things that are known to be broken to many people. If CentOS (wiki?) is able to funnel and manage something like this, I'm sure lots of the same cause-inflicted pain can be transformed into a community of appliance repositories.
If only there would be a good RPM build tool that provide conformance testing with simplicity.
Agreed. I've always had a vision of a few hundred sysadmins being able to publish their carefully tuned and maintained package lists in a way that would allow anyone else to easily duplicate their setup without knowing much about it. In some cases this would involve custom packages but mostly would be specific versions already available but not necessarily the latest in the repositories. In this case the 'testing tool' would be the administrator maintaining the master installation and any number of other machines using his package list would only update to match when he changes his list. Meanwhile very different assortments of packages/versions could also be available in the same repositories without having to maintain a separate repository to match every desired end user configuration.
I think this could sort-of be accomplished with the current tools using some invocation of 'rpm -q' to get a package listing in a format that could be fed to yum to install. To make it really handy, the yum repository configuration would have to also be automatically managed. (But, it never made much sense to me to have a tool that automatically manages your other packages but itself needs hand configuration...).
Kurt Hansen wrote:
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
you are much confused, Kurt, as to what CentOS is and what packaging policy with this distro is. I suggest you spend some time working that out.
this isnt a Gentoo derevative, and never will be either.
Do you have any experience with the rpms to which I'm referring? Do you work with the same software I do?
well, considering you dont know much about the distro you are using, it seems sort of academic to raise this question on your part.
as for the original poster, I'll attempt to upgrade the DVD::RIP on my site - but i *know* there are version conflicts with upstream perl modules required in the dep-chain and centos perl-pkgs / rpmforge perl-packages. Details to follow shortly.
Karanbir Singh wrote:
Kurt Hansen wrote:
Jim Perrin wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
you are much confused, Kurt, as to what CentOS is and what packaging policy with this distro is. I suggest you spend some time working that out.
this isnt a Gentoo derevative, and never will be either.
Oh, so I should use a defective version of mod_perl and a sub-optimal version of perl on my system to maintain the "packaging policy"? When I have a solution that has worked for years, is versatile, and I understand.
Do you have any experience with the rpms to which I'm referring? Do you work with the same software I do?
well, considering you dont know much about the distro you are using, it seems sort of academic to raise this question on your part.
Considering that you don't know much about the software I use, I think you should consider refraining from commenting on my questions. Unless you have something constructive to say rather than make insults.
Regards,
Kurt Hansen
Oh, so I should use a defective version of mod_perl and a sub-optimal version of perl on my system to maintain the "packaging policy"? When I have a solution that has worked for years, is versatile, and I understand.
There are valid reasons to try to stick with RPMs, even when dealing with Perl mods... mainly to keep version sanity, given that you may encounter RPMs that depend on RPMs of Perl mods.
I've had a fair bit of luck with:
http://perl.arix.com/cpan2rpm/
Including building a nice RPM for mod_perl 2.0.2.
cheers, --Matt
Kurt Hansen wrote:
you are much confused, Kurt, as to what CentOS is and what packaging policy with this distro is. I suggest you spend some time working that out.
this isnt a Gentoo derevative, and never will be either.
Oh, so I should use a defective version of mod_perl and a sub-optimal version of perl on my system to maintain the "packaging policy"?
perhaps you dont understand what a package is ? versions of s/w are not locked into packages.... and redhat are not the only people who can create packages. if you google for it, there are many docs out there that explain howto build a rpm, if you like, here are some places to start :
http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF
and...
http://fedora.redhat.com/docs/drafts/rpm-guide-en/
Considering that you don't know much about the software I use, I think you should consider refraining from commenting on my questions. Unless you have something constructive to say rather than make insults.
I would comment on the issues you face, but the darned tonfoil hat keeps getting in the way of my mind scans to transparently read whats on your mind.
- KB
On Thu, 1 Jun 2006, Kurt Hansen wrote:
Jim Perrin wrote:
Kurt Hansen wrote:
In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS
Your logic is confusing to me. It does not resemble what I would consider to be rational thought.
Is this the kind of rhetoric that is acceptable on this list? There is no value to your comment except to insult.
No, it's the kind of rhetoric that should make you reflect on what you've said instead of going into defensive or counter-attack mode.
So let me lighten the pain: CentOS is a rebuild of RHEL. So if the perl-related rpms from Red Hat have a quality problem, the CentOS packages suffer from the same problem.
Do you have any experience with the rpms to which I'm referring? Do you work with the same software I do?
I fail to see why that is relevant in relation to what you stated about RHEL and CentOS. Although I found Jim's response amusing it should have caused self-reflection and maybe self-correction, instead of on outburst.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Although I found Jim's response amusing it should have caused self-reflection and maybe self-correction, instead of on outburst.
I have made Dag smile and managed to start a flame-war all in the same thread. My work here is done. MISSION ACCOMPLISHED
On Thu, 2006-06-01 at 16:46 -0400, Kurt Hansen wrote:
My experience is that I have to watch rpm installed stuff "like a hawk for attempted funky behavior." :-)
It may be my own personal experience, but I've found CPAN easier to control and watch than yum or up2date.
This just depends on the day you try it. The CPAN modules are maintained independently yet many depend on other modules maintained by different people. If you are lucky, everything you need will work together that day. Sometimes you just have to wait a while...
Furthermore, for the stuff I do -- primarily Apache/mod_perl -- I've found the rpms coming out of Red Hat a day late and a dollar short. Either well behind mod_perl development or the perl not optimized for mod_perl. (In fact, the quality of the perl-related rpms from Red Hat is the main reason I'm not using RHEL and using CentOS.) Plus, I've found it easier to understand what is going by using CPAN or compiling from source for these items.
Agreed - the stock RPM packages have the opposite problem - often not being recent enough for apps you want to run. Sometimes you can find where someone else has done the work of packaging the set of modules you need in versions that work together. For example, RT (Request Tracker) needs a huge number of perl modules that aren't included in Centos, but: http://wiki.bestpractical.com/index.cgi?RPMInstall has a link for a simple yum install that gets everything, including a current mod_perl for you.
But, this also could be inertia on my part. :-) CPAN was the easier option when I got started on this a few years back.
Things are coming around - the fedora extras repository for FC5 also has an RPM-packaged RT and all needed modules, so eventually there is hope for a set of packaged modules that will be maintained together.
On Thu, 2006-01-06 at 16:50 -0500, Les Mikesell wrote:
Agreed - the stock RPM packages have the opposite problem - often not being recent enough for apps you want to run. Sometimes you can find where someone else has done the work of packaging the set of modules you need in versions that work together. For example, RT (Request Tracker) needs a huge number of perl modules that aren't included in Centos, but: http://wiki.bestpractical.com/index.cgi?RPMInstall has a link for a simple yum install that gets everything, including a current mod_perl for you.
RT is the only reason why I have always had to resort to CPAN for installing all of the required Perl dependencies on Red Hat based systems. I've been doing it for a few years - not once have I had anything go wrong.
I've read plenty about how one should stick with RPMs on RPM based distros. I've also read many times to avoid CPAN like the plague lest you want a ticking time bomb, but I had no choice when it came to RT (I have limited RPM packaging experience).
The RT RPM option is recent, and it's an excellent option. However, at the moment I'm still running RT on a CentOS 4 box with all of RT's Perl dependencies installed from CPAN. I'm now consolidating everything onto a RHEL 4 box running Xen, so it will be my opportunity to give the RPMs for RT a try.
Maybe now I won't feel so dirty for polluting my Red Hat box. :)
At any rate, to each his own.
Regards,
Ranbir
On Thu, 1 Jun 2006, Kanwar Ranbir Sandhu wrote:
On Thu, 2006-01-06 at 16:50 -0500, Les Mikesell wrote:
Agreed - the stock RPM packages have the opposite problem - often not being recent enough for apps you want to run. Sometimes you can find where someone else has done the work of packaging the set of modules you need in versions that work together. For example, RT (Request Tracker) needs a huge number of perl modules that aren't included in Centos, but: http://wiki.bestpractical.com/index.cgi?RPMInstall has a link for a simple yum install that gets everything, including a current mod_perl for you.
RT is the only reason why I have always had to resort to CPAN for installing all of the required Perl dependencies on Red Hat based systems. I've been doing it for a few years - not once have I had anything go wrong.
I've read plenty about how one should stick with RPMs on RPM based distros. I've also read many times to avoid CPAN like the plague lest you want a ticking time bomb, but I had no choice when it came to RT (I have limited RPM packaging experience).
The RT RPM option is recent, and it's an excellent option. However, at the moment I'm still running RT on a CentOS 4 box with all of RT's Perl dependencies installed from CPAN. I'm now consolidating everything onto a RHEL 4 box running Xen, so it will be my opportunity to give the RPMs for RT a try.
Maybe now I won't feel so dirty for polluting my Red Hat box. :)
What packages do you need in addition to the ones already available from RPMforge ? I'm certainly interested to provide all of these if you send them to suggest@lists.rpmforge.net.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers wrote:
Maybe now I won't feel so dirty for polluting my Red Hat box. :)
What packages do you need in addition to the ones already available from RPMforge ? I'm certainly interested to provide all of these if you send them to suggest@lists.rpmforge.net.
Dag,
http://wiki.centos.org/centoswiki/Repositories
has mention of http://campus.fct.unl.pt/paulomatos/rt/repository/3.4.x/rt-3.4.x.repo which is a functional RT setup.
potential to work together on this one ?
On Fri, 2006-06-02 at 14:37 +0200, Dag Wieers wrote:
The RT RPM option is recent, and it's an excellent option. However, at
the moment I'm still running RT on a CentOS 4 box with all of RT's Perl dependencies installed from CPAN. I'm now consolidating everything onto a RHEL 4 box running Xen, so it will be my opportunity to give the RPMs for RT a try.
Maybe now I won't feel so dirty for polluting my Red Hat box. :)
What packages do you need in addition to the ones already available from RPMforge ? I'm certainly interested to provide all of these if you send them to suggest@lists.rpmforge.net.
The set for RT can be found at: http://campus.fct.unl.pt/paulomatos/rt/repository/3.4.x/SRPMS/ and it all seems to work. However the rt rpm itself is modified to move it's parts into a Redhat-like layout instead of living under the stock /opt/rt3/. Unfortunately this makes it incompatible with 3rd part addons like asset tracker unless they are modified to match. I'm running a hand-built one in production and just testing this - thinking about doing an install to pull in all those perl module dependencies, then removing this RT and dropping in a stock version. I haven't looked at the FC5-packaged version yet to see it it has the same issue - or if the other addons have been packaged there to mach.
Le jeudi 01 juin 2006 à 13:41 -0400, Kurt Hansen a écrit :
To run CPAN,
$ perl -MCPAN -e shell
It'll ask you a bunch of config questions to set up for your environment. You can typically accept the default. Say you want to be asked before installing dependies. Choose a mirror or 2 or 3 near you when that choice comes up. Then, when that is done...
cpan> install DVD::RIP
I'd really like to give this a try. Am I supposed to execute this as root or non-root user? Since I want to install an app that is supposed to be used by all users on a machine...
Cheers,
Niki
Niki Kovacs wrote:
Le jeudi 01 juin 2006 à 13:41 -0400, Kurt Hansen a écrit :
To run CPAN,
$ perl -MCPAN -e shell
It'll ask you a bunch of config questions to set up for your environment. You can typically accept the default. Say you want to be asked before installing dependies. Choose a mirror or 2 or 3 near you when that choice comes up. Then, when that is done...
cpan> install DVD::RIP
I'd really like to give this a try. Am I supposed to execute this as root or non-root user? Since I want to install an app that is supposed to be used by all users on a machine...
If that's the case, do it as root. That's what I typically do.
Take care,
Kurt
Hi Niki,
On Thu, 2006-06-01 at 17:22 +0200, Niki Kovacs wrote:
I want to give DVD::RIP 0.97.10 a try. I enabled rpmforge and kbs repos, but there's only 0.52.2 available, which has an annoying bug in it.
Let me give this a completely different shot: does fixing the bug take substantial changes, or is it fairly simple to fix? If so, I guess it is best to rebuild 0.52.2 with the source RPM, adding the patch. This will avoid all the Perl module upgrade havoc.
As for upgrading/installing via CPAN: I wouldn't do it. I have seen it break things earlier, and it makes system/package administration a lot more difficult.
-- Daniel
Le vendredi 02 juin 2006 à 09:32 +0200, Daniel de Kok a écrit :
Let me give this a completely different shot: does fixing the bug take substantial changes, or is it fairly simple to fix? If so, I guess it is best to rebuild 0.52.2 with the source RPM, adding the patch. This will avoid all the Perl module upgrade havoc.
Hi Daniel,
I'd say that if there is someone to blame, it's the guy who coded DVD::RIP in the first place. So far, it's the best DVD ripping app around, but it's a pain! in! the! ass! to build. Why depend on a myriad of exotic PERL modules in the first place? Things would be so much more simple for everyone if it was just plain GTK2.
But then, as we say in my native Austria: if my grandmother had wheels, she would be a Greyhound bus, and I could go on travel with her.
Cheers,
Niki
Le vendredi 02 juin 2006 à 09:32 +0200, Daniel de Kok a écrit :
Hi Niki,
On Thu, 2006-06-01 at 17:22 +0200, Niki Kovacs wrote:
I want to give DVD::RIP 0.97.10 a try. I enabled rpmforge and kbs repos, but there's only 0.52.2 available, which has an annoying bug in it.
Let me give this a completely different shot: does fixing the bug take substantial changes, or is it fairly simple to fix? If so, I guess it is best to rebuild 0.52.2 with the source RPM, adding the patch. This will avoid all the Perl module upgrade havoc.
Well, in the end I think I found a much more CentOS-compliant solution to fix the problem: use mencoder and transcode on the commandline.
Works A-OK.
Cheers,
Niki
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Dag Wieers -
Daniel de Kok -
Jim Perrin -
Johnny Hughes -
Kanwar Ranbir Sandhu -
Karanbir Singh -
Kurt Hansen -
Les Mikesell -
Matt Rowley -
Niki Kovacs -
Paul Heinlein