Hi all,
This is an interesting thread:
http://lists.centos.org/pipermail/centos/2014-April/141871.html
about the problems you can find building perl modules for CentOS releases (new or old).
I agree with John R. Pierce: cpan is very very bad tool ( in fact, I hate it) to build perl modules for CentOS systems, breaks all other perl modules. I need to use several perl modules in several servers in my dept. and after some tests, I migrate to FreeBSD due to easy install perl modules with poudriere suite.
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
Maybe, it is a good idea to create a CentOS Perl SIG :))
Thanks.
On Tue, Apr 1, 2014 at 1:50 AM, C. L. Martinez carlopmart@gmail.com wrote:
http://lists.centos.org/pipermail/centos/2014-April/141871.html
about the problems you can find building perl modules for CentOS releases (new or old).
I agree with John R. Pierce: cpan is very very bad tool ( in fact, I hate it) to build perl modules for CentOS systems, breaks all other perl modules. I need to use several perl modules in several servers in my dept. and after some tests, I migrate to FreeBSD due to easy install perl modules with poudriere suite.
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
Maybe, it is a good idea to create a CentOS Perl SIG :))
Pretty much everyone needs EPEL for something - so it is not enough to not break anything in CentOS base, but you also need to not break/conflict with/replace anything in EPEL. So really, the best approach would just be to add any missing modules to EPEL.
On Tue, Apr 1, 2014 at 8:44 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Apr 1, 2014 at 1:50 AM, C. L. Martinez carlopmart@gmail.com wrote:
http://lists.centos.org/pipermail/centos/2014-April/141871.html
about the problems you can find building perl modules for CentOS releases (new or old).
I agree with John R. Pierce: cpan is very very bad tool ( in fact, I hate it) to build perl modules for CentOS systems, breaks all other perl modules. I need to use several perl modules in several servers in my dept. and after some tests, I migrate to FreeBSD due to easy install perl modules with poudriere suite.
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
Maybe, it is a good idea to create a CentOS Perl SIG :))
Pretty much everyone needs EPEL for something - so it is not enough to not break anything in CentOS base, but you also need to not break/conflict with/replace anything in EPEL. So really, the best approach would just be to add any missing modules to EPEL.
Thanks Les, but EPEL here it is not an option. I need a lot of perl modules that it doesn't exists in EPEL repos. Yes, I can use some (a few) of perl modules published in EPEL, but they are outdated ... And it is another problem ..
On Wed, Apr 2, 2014 at 12:52 AM, C. L. Martinez carlopmart@gmail.com wrote:
Pretty much everyone needs EPEL for something - so it is not enough to not break anything in CentOS base, but you also need to not break/conflict with/replace anything in EPEL. So really, the best approach would just be to add any missing modules to EPEL.
Thanks Les, but EPEL here it is not an option. I need a lot of perl modules that it doesn't exists in EPEL repos. Yes, I can use some (a few) of perl modules published in EPEL, but they are outdated ... And it is another problem ..
My real point is that you probably do (or will) need some EPEL modules, And unless you are very careful to make RPMs with the same names and higher version numbers for all of your non-base/EPEL modules, it will be very likely that updates or future installs of packaged applications will pull in those older, incompatible modules as dependencies, breaking whatever else you might have installed. So, while it is easy to make something work with a mix of packages and CPAN, they aren't likely to keep working for the life of your system unless you either keep them separate with different paths/library paths that you manage for the non-stock version or careful package naming and numbering to make sure your versions satisfy dependencies and aren't clobbered in updates. And the latter approach can also cause trouble with applications that expect older versions, although perl programmers are normally pretty good about maintaining backwards compatibility.
On Tue, Apr 1, 2014 at 2:50 AM, C. L. Martinez carlopmart@gmail.com wrote:
Hi all,
This is an interesting thread:
http://lists.centos.org/pipermail/centos/2014-April/141871.html
about the problems you can find building perl modules for CentOS releases (new or old).
I agree with John R. Pierce: cpan is very very bad tool ( in fact, I hate it) to build perl modules for CentOS systems, breaks all other perl modules. I need to use several perl modules in several servers in my dept. and after some tests, I migrate to FreeBSD due to easy install perl modules with poudriere suite.
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
Maybe, it is a good idea to create a CentOS Perl SIG :))
Thanks.
Just today I managed to get a modern perl (5.18.2) installed on CentOS 5 using perlbrew. This gives you a complete perl environment in a private location where you can install modules without impacting the system perl. Normally I'm all for using pre-packged RPMs, but the C5 perl is so out of date that it pays off to do it this way instead.
I ran into an issue with the setup script from the web site, and this seems to have worked around it: Download and run the installer like the docs say: curl -kL http://install.perlbrew.pl | bash Manually install patchperl curl -kL https://raw.github.com/gugod/patchperl-packing/master/patchperl > ~/perl5/perlbrew/bin/patchperl chmod +x ~/perl5/perlbrew/bin/patchperl
Full documentation can be found here: http://search.cpan.org/~gugod/App-perlbrew-0.67/lib/App/perlbrew.pm
It doesn't fully integrate into rpm/yum package management, but keeping everything isolated to a private location might be an acceptable compromise for your needs.
❧ Brian Mathis
Brian Mathis wrote:
On Tue, Apr 1, 2014 at 2:50 AM, C. L. Martinez carlopmart@gmail.com wrote:
This is an interesting thread:
http://lists.centos.org/pipermail/centos/2014-April/141871.html
about the problems you can find building perl modules for CentOS releases (new or old).
I agree with John R. Pierce: cpan is very very bad tool ( in fact, I hate it) to build perl modules for CentOS systems, breaks all other perl modules. I need to use several perl modules in several servers in my dept. and after some tests, I migrate to FreeBSD due to easy install perl modules with poudriere suite.
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
Maybe, it is a good idea to create a CentOS Perl SIG :))
Just today I managed to get a modern perl (5.18.2) installed on CentOS 5 using perlbrew. This gives you a complete perl environment in a private location where you can install modules without impacting the system perl. Normally I'm all for using pre-packged RPMs, but the C5 perl is so out of date that it pays off to do it this way instead.
I ran into an issue with the setup script from the web site, and this seems to have worked around it:
<snip> Right. And, um, don't forget to update that local userspace perl, and its modules regularly. And don't wait for the notice of updates or security or bugfixes, since there aren't any....
mark "yummmmmm"
On Tue, Apr 1, 2014 at 4:27 PM, m.roth@5-cent.us wrote:
I ran into an issue with the setup script from the web site, and this seems to have worked around it:
<snip> Right. And, um, don't forget to update that local userspace perl, and its modules regularly. And don't wait for the notice of updates or security or bugfixes, since there aren't any....
I wonder if there could be a way to build a 'userspace' version of fedora/ubuntu or something with faster updates where the entire thing lives in its own path with machine-processed package updates to keep it there. That is, use some other distro's work for the overall internal consistency and dependency management but don't let it break your system stability when you just need to run that one package that needs a newer library/module than CentOS/EPEL provide. It seems like there should be a more lightweight way to do that than running a whole virtual machine. Maybe the concept for RHEL software collections could be generalized to handle any disto's rpm/deb repos in their own area.
On Apr 1, 2014, at 2:52 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Apr 1, 2014 at 4:27 PM, m.roth@5-cent.us wrote:
I ran into an issue with the setup script from the web site, and this seems to have worked around it:
<snip> Right. And, um, don't forget to update that local userspace perl, and its modules regularly. And don't wait for the notice of updates or security or bugfixes, since there aren't any....
I wonder if there could be a way to build a 'userspace' version of fedora/ubuntu or something with faster updates where the entire thing lives in its own path with machine-processed package updates to keep it there. That is, use some other distro's work for the overall internal consistency and dependency management but don't let it break your system stability when you just need to run that one package that needs a newer library/module than CentOS/EPEL provide. It seems like there should be a more lightweight way to do that than running a whole virtual machine. Maybe the concept for RHEL software collections could be generalized to handle any disto's rpm/deb repos in their own area.
This would be possible with a form of containers. The problem I recall from looking at LXC, et el was that it uses the host system’s kernel, which would be either too old or too new depending on how you set up the container....
-- Gary L. Greene, Jr. Sr. Systems Administrator IT Operations Minerva Networks, Inc. Cell: +1 (650) 704-6633
On Tue, Apr 1, 2014 at 5:27 PM, m.roth@5-cent.us wrote:
Brian Mathis wrote:
On Tue, Apr 1, 2014 at 2:50 AM, C. L. Martinez carlopmart@gmail.com wrote:
This is an interesting thread:
http://lists.centos.org/pipermail/centos/2014-April/141871.html
about the problems you can find building perl modules for CentOS releases (new or old).
I agree with John R. Pierce: cpan is very very bad tool ( in fact, I hate it) to build perl modules for CentOS systems, breaks all other perl modules. I need to use several perl modules in several servers in my dept. and after some tests, I migrate to FreeBSD due to easy install perl modules with poudriere suite.
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
Maybe, it is a good idea to create a CentOS Perl SIG :))
Just today I managed to get a modern perl (5.18.2) installed on CentOS 5 using perlbrew. This gives you a complete perl environment in a private location where you can install modules without impacting the system perl. Normally I'm all for using pre-packged RPMs, but the C5 perl is so out of date that it pays off to do it this way instead.
I ran into an issue with the setup script from the web site, and this seems to have worked around it:
<snip>
Right. And, um, don't forget to update that local userspace perl, and its modules regularly. And don't wait for the notice of updates or security or bugfixes, since there aren't any....
mark "yummmmmm"
Mark,
Yes, this is a good point. In a setup like this you are taking responsibility for updates and patching yourself, just like you would for any other set of libraries you use to develop an application. It becomes local to your application and not something you can rely on the operating system to provide, much like many java applications now come with a full version of the JRE they need to work included.
This is the tradeoff you make, but it's not necessarily bad. You can use the OS and patching infrastructure as the foundation for your app, then use whatever you need to actually accomplish your business goal. If that one part of the system needs to be customized, then so be it. After all, that's the reason you're running the server in the first place.
❧ Brian Mathis
On 1 April 2014 07:50, C. L. Martinez carlopmart@gmail.com wrote:
But, anyone knows if it is possible to build a confident devel environment under CentOS with some tool to build rpm's perl modules without breaking anything in CentOS systems??
This is now rather out of date. But it will give you a start.
http://www.slideshare.net/davorg/perl-in-rpmland-presentation
Basically, "cpanspec" will build you a spec file which you can then use with "rpmbuild" to make your rpm.
Dave...