1 |
On Wednesday 11 May 2005 00:49, Antoine Raillon wrote: |
2 |
> Le mardi 10 mai 2005 à 20:32 +0200, Michael Cummings a écrit : |
3 |
> > OK, I'm going to cut this up a little, but to bring everyone into the |
4 |
> > chain for a discussion cab and I were having about g-cpan (or my |
5 |
> > 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 |
12 |
> > > first step ;) |
13 |
> > |
14 |
> > I'd kind of like to keep the upgrade (now that it's there). The idea |
15 |
> > behind it is if user installs module-foo-1 via g-cpan, they can't in the |
16 |
> > old system upgrade it without removing the ebuilds from their overlay. |
17 |
> > This gives them the ability to upgrade, as well as to tweak/update for |
18 |
> > upstream changes. Also means we can say "we don't support it, but use |
19 |
> > g-cpan to upgrade it" (beu knows what i'm talking about re: recent bug |
20 |
> > history) |
21 |
> |
22 |
> Well, ok, let's keep it ;) |
23 |
> It has to be cleaned however ;p |
24 |
> and the --list should also be available (it's probably almost the same |
25 |
> code however ;p) |
26 |
|
27 |
I'll hack this (--list) up at lunch time, if I'm not beaten too it ;) |
28 |
|
29 |
> > >- would a special file dedicated to g-cpan be a good thing ? now that |
30 |
> > > it's a standalone application, we maybe could have it to be a bit |
31 |
> > > bigger. For example, this (these) files could allow us to store ebuild |
32 |
> > > infos (what has already been generated, pathes, versions.. etc), or as |
33 |
> > > small CPAN infos repository, by having an internal db of versions of |
34 |
> > > every modules without having to call CPAN each time we launch g-cpan. a |
35 |
> > > g-cpan --update command would update this mini-db, or we could force it |
36 |
> > > on a regular basis, or add a check in g-cpan. |
37 |
> > |
38 |
> > Not sure I follow (I think I do, but could you expand?) |
39 |
> |
40 |
> Well my original idea was to avoid new downloads each time you run |
41 |
> g-cpan as user to do search. I admit it's a very specific case ;p |
42 |
> Sniper tried to convince me I was wrong, but i'm not totally convinced |
43 |
> yet ;p |
44 |
|
45 |
This sounds useful to me, though it should be configurable (I'd think), so it |
46 |
can be disabled for those not-always-onliner's :) Since a http head request |
47 |
is fairly cheap, we could cache the author/module/all CPAN lists locally, |
48 |
with a 'short' ttl .. only thing with this, is that CPAN will do it itself |
49 |
sooner or later, and might be a tad redundant .. 57/30 on this, I think ;) |
50 |
|
51 |
> > >- Thinking about config and optional options, wouldn't a config file be |
52 |
> > > an helpful thing ? let's say a /etc/g-cpan.conf, that would allow us to |
53 |
> > > store default behaviour, delays between forced update, and such |
54 |
> > > things.. |
55 |
> > |
56 |
> > or ~/.g-cpan.conf since we now support user calls :) |
57 |
> |
58 |
> We support them for searches only ;) |
59 |
> I'd prefer if this file was system-wide, I just think it's the way it |
60 |
> should be =) |
61 |
|
62 |
Surely global and local is a possibility ? :P |
63 |
|
64 |
> > >- a special sub for md5ing things ? ($md5 = md5-sum($file)). It would |
65 |
> > > clean some lines ;) |
66 |
> |
67 |
> I've done this one tonight |
68 |
> |
69 |
> > as well as the whole scanning the tree parts :) |
70 |
> |
71 |
> Tomorrow maybe ? but your code is dense and i don't fully understand |
72 |
> it ;) |
73 |
> /me refuses to broke anything ;p |
74 |
|
75 |
;) |
76 |
|
77 |
> > >- updating exit_usage ;p |
78 |
> > |
79 |
> > yeah - thinking we might not want to remove the generated config for |
80 |
> > cpan, just tell them its there and they can fix it if they want better |
81 |
> > performance |
82 |
|
83 |
/me nods @ ^^ |
84 |
|
85 |
> and checking for what will stay in those ./cpan dirs too (especially if |
86 |
> we use them as local overlays ;p) |
87 |
> |
88 |
> Sniper had some other ideas, but i'll let him introduce them ;) |
89 |
|
90 |
:) |
91 |
|
92 |
Best, |
93 |
Elfyn |
94 |
|
95 |
-- |
96 |
Elfyn McBratney http://beu.merseine.nu/ |
97 |
beu/irc.freenode.net http://dev.gentoo.org/~beu/ |
98 |
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc |
99 |
|
100 |
PGP Key ID: 0x69DF17AD |
101 |
PGP Key Fingerprint: |
102 |
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD |