Gentoo Archives: gentoo-perl

From: Elfyn McBratney <beu@g.o>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;)
Date: Wed, 11 May 2005 09:05:11
Message-Id: 200505111005.13527@zippy.emcb.local
In Reply to: Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) by Antoine Raillon
On Wednesday 11 May 2005 00:49, Antoine Raillon wrote:
> 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)
I'll hack this (--list) up at lunch time, if I'm not beaten too it ;)
> > >- 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
This sounds useful to me, though it should be configurable (I'd think), so it can be disabled for those not-always-onliner's :) Since a http head request is fairly cheap, we could cache the author/module/all CPAN lists locally, with a 'short' ttl .. only thing with this, is that CPAN will do it itself sooner or later, and might be a tad redundant .. 57/30 on this, I think ;)
> > >- 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 =)
Surely global and local is a possibility ? :P
> > >- 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
/me nods @ ^^
> 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 ;)
:) Best, Elfyn -- Elfyn McBratney http://beu.merseine.nu/ beu/irc.freenode.net http://dev.gentoo.org/~beu/ +------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc PGP Key ID: 0x69DF17AD PGP Key Fingerprint: DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD