Re: [gentoo-dev] Re: A few questions to our nominees

[Bernd Steinhauser]

Ryan Hill schrieb:
> 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.
No, the idea behind ESCM_LOGDIR was different.
If you just want the revision of the current installed thing, you can 
grep through the environment.

ESCM_LOGDIR mainly aimed to provide a history of revisions you 
installed. So that you can then tell upstream "Hey, I have this revision 
installed and it doesn't work, but this revision worked.".
So it is definitely related, but not the same.
-- 
gentoo-dev@l.g.o mailing list