Gentoo Archives: gentoo-perl

From: Antoine Raillon <antoine.raillon@××××××.net>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;)
Date: Tue, 10 May 2005 23:49:34
Message-Id: 1115768977.26454.9.camel@dragon
In Reply to: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) by Michael Cummings
Le mardi 10 mai 2005 à 20:32 +0200, Michael Cummings a écrit :
> OK, I'm going to cut this up a little, but to bring everyone into the chain > for a discussion cab and I were having about g-cpan (or my responses) :) > > >- What about the --upgrade ? I'm not sure it's a good idea (at least for > >now). It relys too much on user's behaviour imho, praying that he didn't > >delete/move his overlays/ebuilds. Maybe there could be another way using > >/var/db to find what we need. I think that for now beu's suggestion of a > >simple --list to get all ebuilds handled by g-cpan would be a better first > >step ;) > > I'd kind of like to keep the upgrade (now that it's there). The idea behind it > is if user installs module-foo-1 via g-cpan, they can't in the old system > upgrade it without removing the ebuilds from their overlay. This gives them > the ability to upgrade, as well as to tweak/update for upstream changes. Also > means we can say "we don't support it, but use g-cpan to upgrade it" (beu > knows what i'm talking about re: recent bug history)
Well, ok, let's keep it ;) It has to be cleaned however ;p and the --list should also be available (it's probably almost the same code however ;p)
> >- would a special file dedicated to g-cpan be a good thing ? now that it's > >a standalone application, we maybe could have it to be a bit bigger. For > >example, this (these) files could allow us to store ebuild infos (what has > >already been generated, pathes, versions.. etc), or as small CPAN infos > >repository, by having an internal db of versions of every modules without > >having to call CPAN each time we launch g-cpan. a g-cpan --update command > >would update this mini-db, or we could force it on a regular basis, or add > >a check in g-cpan. > > Not sure I follow (I think I do, but could you expand?)
Well my original idea was to avoid new downloads each time you run g-cpan as user to do search. I admit it's a very specific case ;p Sniper tried to convince me I was wrong, but i'm not totally convinced yet ;p
> >- Thinking about config and optional options, wouldn't a config file be an > >helpful thing ? let's say a /etc/g-cpan.conf, that would allow us to store > >default behaviour, delays between forced update, and such things.. > > or ~/.g-cpan.conf since we now support user calls :)
We support them for searches only ;) I'd prefer if this file was system-wide, I just think it's the way it should be =)
> >- a special sub for md5ing things ? ($md5 = md5-sum($file)). It would clean > >some lines ;)
I've done this one tonight
> as well as the whole scanning the tree parts :)
Tomorrow maybe ? but your code is dense and i don't fully understand it ;) /me refuses to broke anything ;p
> >- updating exit_usage ;p > yeah - thinking we might not want to remove the generated config for cpan, > just tell them its there and they can fix it if they want better performance
and checking for what will stay in those ./cpan dirs too (especially if we use them as local overlays ;p) Sniper had some other ideas, but i'll let him introduce them ;) -- gentoo-perl@g.o mailing list


Subject Author
Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) "David (Sniper) Rigaudiere" <sniper@×××××××××.net>
Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) Michael Cummings <mcummings@g.o>
Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) Elfyn McBratney <beu@g.o>