On Tue, 5 Feb 2013 10:47:11 -0600
Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> On Tue, Feb 5, 2013 at 10:22 AM, James Szinger <jszinger@xxxxxxxxx>
> wrote:
> > You should check out cpanspec, available from EPEL, which makes it
> > easy to package CPAN modules into RPMs. Well-behaved modules are
> > nearly trivial and the Fedora Packing Guideline help make sane
> > packages out of the more complicated modules. Then build with mock
> > and put the RPM into a local repository and manage with yum. You
> > might need to iterate a few time to satisfy all the dependencies,
> > but that's a one-time deal.
>
> That keeps your rpm database happy, but it doesn't solve the real
> problem which is that CPAN modules can and do change in ways that make
> previously working combinations break. It may be rare these days, but
> it happens. And the value of having centrally packaged modules is
> that (a) the versions released together are generally tested together
> and (b) even if some bug slips by the release process, a lot of other
> people will be using the same set and can share the debugging effort
> and knowledge of the fix.
Any program or library can break---that's why we test and verify. A
proper package management system helps, but is not a panacea.
I only do this if I can't find a package from a trusted repository. I
even try to rebuild the Fedora RPMs if they are available. Once I have
an RPM, I can test it and then deploy to production. The spec
file is record of how the package is built and mock helps protect
against hidden dependecies. Having an RPM also allows for a broken
package to be downgraded or removed. I have suffered enough problems
from source installs and don't want to do it that way again.
>
> > The only real problem I've encountered is a program that wants to
> > update a core perl module and RPM rightly complains about that. If
> > had used cpan directly, I would not have been warned about the
> > conflict and might have ended up with a broken system.
>
> That's just one of the ways things can break, though.
It was enough to get me to drop back and punt and wait until upstream
fixes their code or I can develop a patch.
Jim
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
