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
|
