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--------------------------------------------- |