Ryan Hill schrieb:
On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> 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@lists.gentoo.org mailing list
