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