1 |
On Sat, 14 Jun 2008 11:53:51 +0200 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
|
4 |
> Ciaran McCreesh wrote: |
5 |
> > On Sat, 14 Jun 2008 10:19:32 +0200 |
6 |
> > Luca Barbato <lu_zero@g.o> wrote: |
7 |
> >>> I'm confused. If I have a gcc-4.4.0.live ebuild which checks out |
8 |
> >>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737 |
9 |
> >>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) |
10 |
> >>> installed? |
11 |
> >> it would be gcc-4.4.0_pre1 but you'll have the revision inside the |
12 |
> >> ebuild as var so you can get it easily. (e.g. the description shows |
13 |
> >> it) |
14 |
> > |
15 |
> > And when would gcc-4.4.0_pre2 become available? |
16 |
> |
17 |
> It will be available once you trigger again the generation or if you |
18 |
> put a normal ebuild with such name. |
19 |
|
20 |
So every user will have a different _preN version which would vary |
21 |
depending on how often they rebuild the package and that has absolutely |
22 |
no correlation with the revision number of the upstream codebase. I'm |
23 |
sorry, but that's unacceptable. :/ |
24 |
|
25 |
If a user reports a bug in package-1.1_pre6, how do you determine what |
26 |
revision he has installed? How can you even tell it's an scm ebuild? |
27 |
If I want to report a bug I find to upstream, how to I know what |
28 |
revision I have? Yes there are hacks like ESCM_LOGDIR, but they're |
29 |
different for every SCM and you have to opt-in to use them. Most |
30 |
people don't even know about them. |
31 |
|
32 |
I think the request to create some kind of auto-updating system for |
33 |
live ebuilds is a red herring, and will make finding a reasonable |
34 |
solution much much harder than it should be. If people want to |
35 |
auto-update their live ebuilds they can simply put them in a cron job. |
36 |
|
37 |
|
38 |
-- |
39 |
gcc-porting, by design, by neglect |
40 |
treecleaner, for a fact or just for effect |
41 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |