On 25 May 2012 20:52, Grant <emailgrant@...> wrote:
> I switched local-lib from the g-cpan one to the perl-experimental one
> and all is well as far as installation all the way through
> Net-Braintree. Thank you very much for sticking with me on this guys.
>
> May I ask why you force the g-cpan category to dev-perl?
Using that category solves many issues in advance, ie: if you
generated an ebuild locally, and then we provided a maintained copy,
portage would just switch from one to the other seamlessly where
needed without you having to modify all ebuilds that depend on it.
ie:
if a package was installed in perl-gcpan/ instead ( which used to be
the case iirc ), you then have:
perl-gcpan/foo : DEPENDS dev-perl/bar
perl-gcpan/baz : DEPENDS perl-gcpan/foo
And if you want to cede development of "foo" to an overlay/gentoo,
you'd have to change perl-gcpan/baz to point to perl-gcpan/foo
instead.
With the packages all in dev-perl, no such changes are required.
>
> To what extent is running ebuilds from perl-experimental a safe endeavor?
It should be reasonably safe, but If you want to be sure, I advise
enabling tests.
---[ /etc/portage/package.env ]---
dev-perl/* perlmod.conf
-----------------------------------------
---[ /etc/portage/env/perlmod.conf ]---
FEATURES="${FEATURES} test"
----------------------------------------------
And this will at least give you the same level of assurance as you
would get if you were installing the packages with a CPAN client.
We do our best to make the overlay stable somewhat, but it will always
be somewhat less important than the main tree
> Should Net-Braintree or any of the ebuilds I had g-cpan trouble with
> be eligible for inclusion in the main tree or perl-experimental?
I've it on my mental TODO list, just a lot of other things I'm behind
schedule in updating atm.
> Thanks again,
> Grant
>
--
Kent
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz
|
