On Tue, Feb 5, 2013 at 10:22 AM, James Szinger <jszinger@xxxxxxxxx> wrote:
>
>> As I keep noting, many perl CPAN packages are available as rpms - I know,
>> since my manager prefers we not build any from CPAN unless it's a) not
>> available from a trusted repository as an rpm, and b) actually required by
>> a developer. As an rpm, of course, if there's an update, it'll get taken
>> care of the next update we do; otherwise, we have to remember which of our
>> 150 or so systems has what that has to be built.
>
> 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.
> 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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
