On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <lu_zero@g.o> wrote:

> Ciaran McCreesh wrote:
> > On Sat, 14 Jun 2008 10:19:32 +0200
> > Luca Barbato <lu_zero@g.o> wrote:
> >>> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
> >>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737
> >>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
> >>> installed?
> >> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
> >> ebuild as var so you can get it easily. (e.g. the description shows
> >> it)
> > 
> > And when would gcc-4.4.0_pre2 become available?
> 
> It will be available once you trigger again the generation or if you
> put a normal ebuild with such name.

So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has absolutely
no correlation with the revision number of the upstream codebase.  I'm
sorry, but that's unacceptable. :/

If a user reports a bug in package-1.1_pre6, how do you determine what
revision he has installed?  How can you even tell it's an scm ebuild?
If I want to report a bug I find to upstream, how to I know what
revision I have?  Yes there are hacks like ESCM_LOGDIR, but they're
different for every SCM and you have to opt-in to use them.  Most
people don't even know about them.

I think the request to create some kind of auto-updating system for
live ebuilds is a red herring, and will make finding a reasonable
solution much much harder than it should be.  If people want to
auto-update their live ebuilds they can simply put them in a cron job.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662