1 |
Le mardi 10 mai 2005 à 20:32 +0200, Michael Cummings a écrit : |
2 |
> OK, I'm going to cut this up a little, but to bring everyone into the chain |
3 |
> for a discussion cab and I were having about g-cpan (or my responses) :) |
4 |
> |
5 |
> >- What about the --upgrade ? I'm not sure it's a good idea (at least for |
6 |
> >now). It relys too much on user's behaviour imho, praying that he didn't |
7 |
> >delete/move his overlays/ebuilds. Maybe there could be another way using |
8 |
> >/var/db to find what we need. I think that for now beu's suggestion of a |
9 |
> >simple --list to get all ebuilds handled by g-cpan would be a better first |
10 |
> >step ;) |
11 |
> |
12 |
> I'd kind of like to keep the upgrade (now that it's there). The idea behind it |
13 |
> is if user installs module-foo-1 via g-cpan, they can't in the old system |
14 |
> upgrade it without removing the ebuilds from their overlay. This gives them |
15 |
> the ability to upgrade, as well as to tweak/update for upstream changes. Also |
16 |
> means we can say "we don't support it, but use g-cpan to upgrade it" (beu |
17 |
> knows what i'm talking about re: recent bug history) |
18 |
|
19 |
Well, ok, let's keep it ;) |
20 |
It has to be cleaned however ;p |
21 |
and the --list should also be available (it's probably almost the same |
22 |
code however ;p) |
23 |
|
24 |
> >- would a special file dedicated to g-cpan be a good thing ? now that it's |
25 |
> >a standalone application, we maybe could have it to be a bit bigger. For |
26 |
> >example, this (these) files could allow us to store ebuild infos (what has |
27 |
> >already been generated, pathes, versions.. etc), or as small CPAN infos |
28 |
> >repository, by having an internal db of versions of every modules without |
29 |
> >having to call CPAN each time we launch g-cpan. a g-cpan --update command |
30 |
> >would update this mini-db, or we could force it on a regular basis, or add |
31 |
> >a check in g-cpan. |
32 |
> |
33 |
> Not sure I follow (I think I do, but could you expand?) |
34 |
|
35 |
Well my original idea was to avoid new downloads each time you run |
36 |
g-cpan as user to do search. I admit it's a very specific case ;p |
37 |
Sniper tried to convince me I was wrong, but i'm not totally convinced |
38 |
yet ;p |
39 |
|
40 |
> >- Thinking about config and optional options, wouldn't a config file be an |
41 |
> >helpful thing ? let's say a /etc/g-cpan.conf, that would allow us to store |
42 |
> >default behaviour, delays between forced update, and such things.. |
43 |
> |
44 |
> or ~/.g-cpan.conf since we now support user calls :) |
45 |
|
46 |
We support them for searches only ;) |
47 |
I'd prefer if this file was system-wide, I just think it's the way it |
48 |
should be =) |
49 |
|
50 |
> >- a special sub for md5ing things ? ($md5 = md5-sum($file)). It would clean |
51 |
> >some lines ;) |
52 |
|
53 |
I've done this one tonight |
54 |
|
55 |
> as well as the whole scanning the tree parts :) |
56 |
|
57 |
Tomorrow maybe ? but your code is dense and i don't fully understand |
58 |
it ;) |
59 |
/me refuses to broke anything ;p |
60 |
|
61 |
> >- updating exit_usage ;p |
62 |
> yeah - thinking we might not want to remove the generated config for cpan, |
63 |
> just tell them its there and they can fix it if they want better performance |
64 |
|
65 |
and checking for what will stay in those ./cpan dirs too (especially if |
66 |
we use them as local overlays ;p) |
67 |
|
68 |
Sniper had some other ideas, but i'll let him introduce them ;) |
69 |
|
70 |
|
71 |
-- |
72 |
gentoo-perl@g.o mailing list |