1 |
/me waves @ new list :) |
2 |
|
3 |
On Tuesday 10 May 2005 19:32, Michael Cummings wrote: |
4 |
> OK, I'm going to cut this up a little, but to bring everyone into the chain |
5 |
> for a discussion cab and I were having about g-cpan (or my responses) :) |
6 |
> |
7 |
> >- What about the --upgrade ? I'm not sure it's a good idea (at least for |
8 |
> >now). It relys too much on user's behaviour imho, praying that he didn't |
9 |
> >delete/move his overlays/ebuilds. Maybe there could be another way using |
10 |
> >/var/db to find what we need. I think that for now beu's suggestion of a |
11 |
> >simple --list to get all ebuilds handled by g-cpan would be a better first |
12 |
> >step ;) |
13 |
> |
14 |
> I'd kind of like to keep the upgrade (now that it's there). The idea behind |
15 |
> it is if user installs module-foo-1 via g-cpan, they can't in the old |
16 |
> system upgrade it without removing the ebuilds from their overlay. This |
17 |
> gives them the ability to upgrade, as well as to tweak/update for upstream |
18 |
> changes. Also means we can say "we don't support it, but use g-cpan to |
19 |
> upgrade it" (beu knows what i'm talking about re: recent bug history) |
20 |
|
21 |
Exactly, this is a perfect reason to keep, and improve upon the notion of |
22 |
`g-cpan --upgrade`, imo. :) Being able to respond to bug reports with a |
23 |
`g-cpan --upgrade whatever ..` and fix a user issue (come up quite few times |
24 |
in the month and a half that i've been on perl@, as Mike mentioned ;) makes |
25 |
all our bug-wrangling lives easier. |
26 |
|
27 |
Expanding on this a little, and now vdb has been mentioned ;), we could have, |
28 |
say, a --check-origin option to g-cpan - which would check for a |
29 |
tag/identifier in the ebuild in the vdb denoting that it was created by |
30 |
g-cpan - to ascertain whether or not the ebuild was installed via g-cpan |
31 |
(duh ;) or not .. not something that would be as useful now, but in time once |
32 |
such a thing is wide-spread .. lemme know if I'm way of base 'ere ;) |
33 |
|
34 |
> >- would a special file dedicated to g-cpan be a good thing ? now that it's |
35 |
> >a standalone application, we maybe could have it to be a bit bigger. For |
36 |
> >example, this (these) files could allow us to store ebuild infos (what has |
37 |
> >already been generated, pathes, versions.. etc), or as small CPAN infos |
38 |
> >repository, by having an internal db of versions of every modules without |
39 |
> >having to call CPAN each time we launch g-cpan. a g-cpan --update command |
40 |
> >would update this mini-db, or we could force it on a regular basis, or add |
41 |
> >a check in g-cpan. |
42 |
> |
43 |
> Not sure I follow (I think I do, but could you expand?) |
44 |
|
45 |
gcpan-world, anyone ? :) Like the --check-origin idea above, with the |
46 |
metadata cab mentioned (installed cpv (category, package and version) next |
47 |
available cpv - the upgrade option, etc.), stored somewhere for later |
48 |
inspection, etc. |
49 |
|
50 |
Thinking about this some (probably duplicating parts or all of what cab was |
51 |
thinking ;), we could do the following on a new install/upgrade of an |
52 |
existing g-cpan'd ebuild: |
53 |
|
54 |
- check for the latest cpan version of foo; |
55 |
- grab the latest versions of foo's dependencies (if any); |
56 |
- write that out to a world/avail. file (a saved-state thing) |
57 |
- use it on the next g-cpan run (upgrade if not within a set 'cache ttl' |
58 |
|
59 |
With that (getting slightly adventurous) we could implement things like |
60 |
CPAN-dependency listings (a la `emerge -pvt dev-perl/Foo` - without having to |
61 |
actually make the ebuilds), --pretend (you know what that'd do ;), --sync |
62 |
(update metadata from CPAN, maybe even fetching the Xmodules.txt (tho |
63 |
CPAN.pm'll do this every other day when said files are updated), etc. files |
64 |
and stashing them locally, .. |
65 |
|
66 |
</muse> :P |
67 |
|
68 |
> >- Thinking about config and optional options, wouldn't a config file be an |
69 |
> >helpful thing ? let's say a /etc/g-cpan.conf, that would allow us to store |
70 |
> >default behaviour, delays between forced update, and such things.. |
71 |
> |
72 |
> or ~/.g-cpan.conf since we now support user calls :) |
73 |
|
74 |
Oooh, +1 :D |
75 |
|
76 |
> >smaller things : |
77 |
> > |
78 |
> >- a special sub for md5ing things ? ($md5 = md5-sum($file)). It would |
79 |
> > clean some lines ;) |
80 |
> |
81 |
> as well as the whole scanning the tree parts :) |
82 |
> |
83 |
> >- updating exit_usage ;p |
84 |
> |
85 |
> yeah - thinking we might not want to remove the generated config for cpan, |
86 |
> just tell them its there and they can fix it if they want better |
87 |
> performance |
88 |
> |
89 |
> >That's all for his hour |
90 |
> >Am i thinking too much ? :) |
91 |
> |
92 |
> maybe :) |
93 |
|
94 |
This is all sounding cool, be is excited. :) |
95 |
|
96 |
Best, |
97 |
Elfyn |
98 |
|
99 |
-- |
100 |
Elfyn McBratney http://beu.merseine.nu/ |
101 |
beu/irc.freenode.net http://dev.gentoo.org/~beu/ |
102 |
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc |
103 |
|
104 |
PGP Key ID: 0x69DF17AD |
105 |
PGP Key Fingerprint: |
106 |
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD |