On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato <lu_zero@g.o> wrote:

> Ryan Hill wrote:
> > 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. :/
> 
> You'd like to have the cflags and ldflags embedded in the name for
> the same reason?

There's no need to set up a strawman.  I expect that everyone
installing a version of a package is building from the same sources.
Do you really not see a problem here?

Okay, taking a different approach, what does an auto-incrementing
suffix gain us?  The ability to auto-merge a live ebuild at regular
intervals?  That's something that can easily be achieved without
mucking about mangling CPVs, in any implementation we decide on.  What
is it about your particular idea that makes it worth the numerous
disadvantages that we've pointed out?

> > 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?
> 
> You can. The generated ebuild must have a reference to the checkout.

This is the first time you've mentioned this.  Where would you find
such information?  How would you know that the ebuild the user is using
is a generated ebuild, and not just a standard ebuild that happens to
end in _pre6?  How would that information get into the ebuild?  Would
it have to come from the various VCS eclasses?  What about those that
don't have a way of getting at the revision number (like say
cvs.eclass)?  Would it have to be placed there by the package manager?
If so, then we're back to having to implement support for every VCS
inside the PM.

> > 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.
> 
> The generated ebuild contains pretty much everything you need to fill
> a bugreport.

Could you please provide an example of a generated ebuild so we can see
what kinds of info it contains?


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