Gentoo Archives: gentoo-perl

From: Michael Cummings <mcummings@g.o>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;)
Date: Thu, 12 May 2005 12:01:02
In Reply to: Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) by Elfyn McBratney
On Wednesday 11 May 2005 04:58 am, Elfyn McBratney wrote:
> /me waves @ new list :)
/me waves back ;)
> > Exactly, this is a perfect reason to keep, and improve upon the notion of > `g-cpan --upgrade`, imo. :) Being able to respond to bug reports with a > `g-cpan --upgrade whatever ..` and fix a user issue (come up quite few > times in the month and a half that i've been on perl@, as Mike mentioned ;) > makes all our bug-wrangling lives easier. > > Expanding on this a little, and now vdb has been mentioned ;), we could > have, say, a --check-origin option to g-cpan - which would check for a > tag/identifier in the ebuild in the vdb denoting that it was created by > g-cpan - to ascertain whether or not the ebuild was installed via g-cpan > (duh ;) or not .. not something that would be as useful now, but in time > once such a thing is wide-spread .. lemme know if I'm way of base 'ere ;)
Actually, this was the idea behind having all of the g-cpan ebuilds (when an overlay is present) to be stored in $overlay/perl-gcpan - if it's in perl-gcpan, then its their problem so to speak. For that matter, even if they don't have an overlay, when they emerge the temp file a copy of the ebuild is being plopped in /var/db/pkg/perl-gcpan/ anyway, so either way we have a means of identifying those ebuilds without any special tags (unless you twist my arm real nice, in which case I'll agree to anything :) Also, fwiw, the upgrade functions got cleaned a little bit yesterday :)
> - check for the latest cpan version of foo;
> - grab the latest versions of foo's dependencies (if any);
> - write that out to a world/avail. file (a saved-state thing)
> - use it on the next g-cpan run (upgrade if not within a set 'cache ttl'
done i think - not clear on the cache stuff (just groggy)
> With that (getting slightly adventurous) we could implement things like > CPAN-dependency listings (a la `emerge -pvt dev-perl/Foo` - without having > to actually make the ebuilds), --pretend (you know what that'd do ;), > --sync (update metadata from CPAN, maybe even fetching the Xmodules.txt > (tho'll do this every other day when said files are updated), etc. > files and stashing them locally, .. >
-pv works now. If they have an overlay and the ebuild was stored, even if they didn't emerge it last time it's still available to emerge -pv output ;) As for the syncing - cpan updates its metalist based on a time default (1 day i think is the generic), so i'm leary of this whole synching again thing...but I don't think I'm understanding the implications completely either :) ok, on to the next email i didn't answer... ~M -- -----o()o--------------------------------------------- Michael Cummings | #gentoo-dev, #gentoo-perl Gentoo Perl Dev | on -----o()o---------------------------------------------