1 |
On Sat, 14 Jun 2008 17:55:27 +0200 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
|
4 |
> Ryan Hill wrote: |
5 |
> > So every user will have a different _preN version which would vary |
6 |
> > depending on how often they rebuild the package and that has |
7 |
> > absolutely no correlation with the revision number of the upstream |
8 |
> > codebase. I'm sorry, but that's unacceptable. :/ |
9 |
> |
10 |
> You'd like to have the cflags and ldflags embedded in the name for |
11 |
> the same reason? |
12 |
|
13 |
There's no need to set up a strawman. I expect that everyone |
14 |
installing a version of a package is building from the same sources. |
15 |
Do you really not see a problem here? |
16 |
|
17 |
Okay, taking a different approach, what does an auto-incrementing |
18 |
suffix gain us? The ability to auto-merge a live ebuild at regular |
19 |
intervals? That's something that can easily be achieved without |
20 |
mucking about mangling CPVs, in any implementation we decide on. What |
21 |
is it about your particular idea that makes it worth the numerous |
22 |
disadvantages that we've pointed out? |
23 |
|
24 |
> > If a user reports a bug in package-1.1_pre6, how do you determine |
25 |
> > what revision he has installed? How can you even tell it's an scm |
26 |
> > ebuild? |
27 |
> |
28 |
> You can. The generated ebuild must have a reference to the checkout. |
29 |
|
30 |
This is the first time you've mentioned this. Where would you find |
31 |
such information? How would you know that the ebuild the user is using |
32 |
is a generated ebuild, and not just a standard ebuild that happens to |
33 |
end in _pre6? How would that information get into the ebuild? Would |
34 |
it have to come from the various VCS eclasses? What about those that |
35 |
don't have a way of getting at the revision number (like say |
36 |
cvs.eclass)? Would it have to be placed there by the package manager? |
37 |
If so, then we're back to having to implement support for every VCS |
38 |
inside the PM. |
39 |
|
40 |
> > If I want to report a bug I find to upstream, how to I know what |
41 |
> > revision I have? Yes there are hacks like ESCM_LOGDIR, but they're |
42 |
> > different for every SCM and you have to opt-in to use them. Most |
43 |
> > people don't even know about them. |
44 |
> |
45 |
> The generated ebuild contains pretty much everything you need to fill |
46 |
> a bugreport. |
47 |
|
48 |
Could you please provide an example of a generated ebuild so we can see |
49 |
what kinds of info it contains? |
50 |
|
51 |
|
52 |
-- |
53 |
gcc-porting, by design, by neglect |
54 |
treecleaner, for a fact or just for effect |
55 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |