On 21 May 2009, at 22:23, Tim Jones wrote:
...
I was a little confused to learn of the existence of the g-cpan
module, even at the presence of perl modules in Portage itself.
I don't know how other distros handle this. I'd imagine that most
package managers allow the installation of some Perl modules, but not
the entire range offered by cpan. (??)
g-cpan is supposed to be a Portage wrapper for plain cpan?
Yes.
If I use g-cpan to install a module, will it use the ebuild, if one
exists?
I think you use Portage - e.g. `emerge dev-perl/libwww-perl` if the
package exists, otherwise g-cpan.
Is there anything wrong with using plain cpan? (It would bother me
if there was not agreement between my local Portage tree and what is
actually installed on my system.)
That's exactly why you'd use g-cpan - Portage doesn't know the module
is installed on your system, otherwise, and can't apply updates to it.
I guess I am just feeling that someone tried to fix something that
wasn't broken.
The thing is that a package in Portage might depend on cpan modules.
Portage isn't able to itself automatically get stuff from cpan's
archive and so it's unable to fullfill the dependencies for that.
That's why Perl library packages exist within the portage tree.
I suspect the ideal situation would be for ANY Perl dependency to call
g-cpan, but g-cpan is relatively new, and probably not ready for that.
I would guess that most of the major Perl packages are already in the
main Portage tree, and g-cpan isn't much of a development priority.
I wouldn't use the standalone cpan tools myself, because they might
install things in non-Gentoo places, or Portage might delete them
without warning you. The whole point of the g-cpan wrapper is to avoid
this happening.
I hope this makes sense. I have to say that I've used g-cpan a couple
of times myself, but don't have a complete understanding of it. I
didn't know what cpan was before needing to use g-cpan.
Stroller.
