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