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.
I think I understand what he was trying to say. When I built my last system, I decided to go with rpms for everything. It worked great until I got to the Perl modules and then it fell apart.
Every time I have tried to install Perl modules from rpms, it quickly evolves into a massive game of "find the missing dependency". Either the module I want can't be found anywhere, or when I do find it, it depends on a module that can't be found.
I finally gave up and decided to use CPAN for Perl modules. It is simple, and work amazingly well. It does cause some annoyance when you get other rpms that have dependencies on Perl modules, but that is a problem that I have only seen once or twice.
There is a program that will create rpms from CPAN. I considered it and then rejected it as being WAY too much trouble for the number of modules that I typically deal with.
Bowie Bailey 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.
I think I understand what he was trying to say. When I built my last system, I decided to go with rpms for everything. It worked great until I got to the Perl modules and then it fell apart.
details please :)
Every time I have tried to install Perl modules from rpms, it quickly evolves into a massive game of "find the missing dependency". Either the module I want can't be found anywhere, or when I do find it, it depends on a module that can't be found.
that sounds like a broken repo, have you raised the issue with the repo maintainers ? if so, do you have some specific bug numbers / issue reports highlighting this issue ?
I finally gave up and decided to use CPAN for Perl modules. It is simple, and work amazingly well. It does cause some annoyance when you get other rpms that have dependencies on Perl modules, but that is a problem that I have only seen once or twice.
CPAN has a boatload more mod's than rpm based repo's do at this time, then there is the issue of matching perl versions and other fluff around them. Rpm based repo's try to address this issue as much as possible and try and do this in a way that relates more from the app -> dep end ( in that pick the app, then build the perl dep tree under it ) rather than just mass build cpan modules into rpm's. I suppose it would be a good effort, if someone can do this sort of a thing for a stable distro like CentOS.
There is a program that will create rpms from CPAN. I considered it and then rejected it as being WAY too much trouble for the number of modules that I typically deal with.
cpanflute, is perhaps the app you are talking about. It _can_ do some fairly sane .spec's but you do need to know whats going on and in 30 - 40% of the cases, need a minor tweak to make things all good.
while we are all talking about perl modules, there is a move underway on rpm development to get depsolving against cpan installed perl modules ( and similar stuff for python and ruby etc as well ), but its not there in CentOS - so if its a proper homogenius system you need and want to track ( every good systemadmin should, imho ), rpm based perl mod installs is your best bet. And in a lot of the cases, asking on the right list, issue tracker, will get the desired results.
On Thu, Jun 01, 2006 at 05:13:00PM -0400, Bowie Bailey said:
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.
I think I understand what he was trying to say. When I built my last system, I decided to go with rpms for everything. It worked great until I got to the Perl modules and then it fell apart.
Every time I have tried to install Perl modules from rpms, it quickly evolves into a massive game of "find the missing dependency". Either the module I want can't be found anywhere, or when I do find it, it depends on a module that can't be found.
I finally gave up and decided to use CPAN for Perl modules. It is simple, and work amazingly well. It does cause some annoyance when you get other rpms that have dependencies on Perl modules, but that is a problem that I have only seen once or twice.
There is a program that will create rpms from CPAN. I considered it and then rejected it as being WAY too much trouble for the number of modules that I typically deal with.
As another software engineer / sysadmin that supports a large mod_perl based site (about 50 servers now) I have to echo this. The latest greatest RHEL/CentOS 4.3 perl and associated modules is WAY too old.
I deal with well over a hundred additional perl modules beyond what is supported in the base OS, and have been hammered by bugs in old modules / perl. If you are heavy users of perl, it is simply not possible to avoid CPAN, and not possible to use the versions of modules supplied in the base OS. I use stock packages for everything possible except apache / perl which all lives in /usr/local - easily replicated from system to system. I frankly don't have time to build RPM's of every CPAN module I use. It would take me an extra year of labor and I just don't have that kind of time / money to waste on purist ideals - I live in the real world.
I have had ZERO issues over the past several years pointing /usr/bin/perl to /usr/local/bin/perl as the local perl is a superset of stock perl. Local scripts work fine.
The problem is basically mirrored with PHP with many advanced applications requiring versions newer than the OS is bundled with.
On Fri, Jun 02, 2006 at 05:33:27AM -0400, Walt Reed wrote:
On Thu, Jun 01, 2006 at 05:13:00PM -0400, Bowie Bailey said:
I finally gave up and decided to use CPAN for Perl modules. It is simple, and work amazingly well. It does cause some annoyance when you get other rpms that have dependencies on Perl modules, but that is a problem that I have only seen once or twice.
There is a program that will create rpms from CPAN. I considered it and then rejected it as being WAY too much trouble for the number of modules that I typically deal with.
As another software engineer / sysadmin that supports a large mod_perl based site (about 50 servers now) I have to echo this. The latest greatest RHEL/CentOS 4.3 perl and associated modules is WAY too old.
I deal with well over a hundred additional perl modules beyond what is supported in the base OS, and have been hammered by bugs in old modules / perl. If you are heavy users of perl, it is simply not possible to avoid CPAN, and not possible to use the versions of modules supplied in the base OS. I use stock packages for everything possible except apache / perl which all lives in /usr/local - easily replicated from system to system. I frankly don't have time to build RPM's of every CPAN module I use. It would take me an extra year of labor and I just don't have that kind of time / money to waste on purist ideals - I live in the real world.
I have had ZERO issues over the past several years pointing /usr/bin/perl to /usr/local/bin/perl as the local perl is a superset of stock perl. Local scripts work fine.
The problem is basically mirrored with PHP with many advanced applications requiring versions newer than the OS is bundled with.
+1. Personally, I think there are probably two classes of system being represented here - standard server installs which use a small to moderate set of perl modules basically as OS components, and perl application/web servers whose main purpose is running (often custom) perl apps with much larger numbers of modules, often with specific version requirements.
In the former case you can often get away with sticking to using perl RPMs and you get the audit, consistency, and homogeneity benefits that come with that. But for the second case the convenience and breadth of CPAN simply outweighs the benefits of a more rigorous package-based approach.
Another useful option for those who decide to go the CPAN route is to investigate the CPAN::Mini family of modules, which allow you to setup a local CPAN mirror on your lan (analogous to a local yum repository) and have your local machines use that, ensuring consistency across your machines, and allowing you to control the rate at which you accept changes from upstream, etc.
Cheers, Gavin
Walt Reed wrote:
I have had ZERO issues over the past several years pointing /usr/bin/perl to /usr/local/bin/perl as the local perl is a superset of stock perl. Local scripts work fine.
if you really do have 50+ machines, surely a rpm'ised yum repo is going to save you much heartache ??? or is manually using cpan on each machine really all that much better ?
The problem is basically mirrored with PHP with many advanced applications requiring versions newer than the OS is bundled with.
the problem with php is a lot easier to address, and we try and do that via the centosplus repo, where we provide a newer php, not tested nearly as much as base is - and not nearly as long a lifeline as the base packages are - but we try and help.
we've also been working on seeing how we can get php-pear packages setup and sorted in a sane manner. Things should get a lot easier with CentOS5, when the php packaging policy changes a bit upstream, but for that, we shall see :)
one of the reasons that I mentioned the rpm issue ( w.r.t rpmdeps --perl format ), where rpm can look at and dep solve from installed perl modules is because this functionality is seen as critical in the future. Imagine, perl - python - ruby - php - apache - third party drivers - mysql - etc etc, all of them with thier own install and management process ( not unlike CPAN is for perl )....
it _IS_ going to come, but its not here yet. And to be honest, end of the day, its a free world. Every systemadmin has his/her right to do as they choose, its their system and how they manage it is, well, upto them. And we are all just expressing opinion here. If you can take centos and stretch it in any manner you like to make it more usable by you - hey, more power to you.
-
Bowie Bailey -
Gavin Carr -
Karanbir Singh -
Walt Reed