1 |
On Fri, 13 Jun 2008 13:35:52 +0200 |
2 |
Marius Mauch <genone@g.o> wrote: |
3 |
|
4 |
> Ignoring possible semantic issues for the moment, I'd be against this |
5 |
> simply because it would require the PM to be aware of the current |
6 |
> revision of the repository and to transform it into a integer value |
7 |
> (trivial for SVN, not so trivial for CVS for example). Which in turn |
8 |
> either means that the PM has to internally support the SCMs or support |
9 |
> some new phase functions to extract the revision. |
10 |
|
11 |
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. |
12 |
136737, after the merge do I have gcc-4.4.0_pre136737 |
13 |
or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) |
14 |
installed? |
15 |
|
16 |
The latter would be quite a nightmare. A bug report about an |
17 |
error in package-1.1_pre6 isn't really helpful when everyone's _pre6 is |
18 |
a completely different revision. |
19 |
|
20 |
The former, as Marius said, requires knowledge of how to get a sane |
21 |
revision id from every SCM we want to support to be built into |
22 |
the package manager. |
23 |
|
24 |
I wonder if instead of rev id, we could use a timestamp to fill in |
25 |
_pre. It's not ideal but it narrows the checkout down somewhat. |
26 |
Also, we could use pkg_info to report revision numbers (for those SCM's |
27 |
that have such a thing). The combination of the two might be enough - |
28 |
you'd have the revision you installed, when you installed it, and an |
29 |
automatic incrementor for those ppl who like those kinds of things. |
30 |
|
31 |
> * How are you planning to handle reinstalls? Should installing world |
32 |
> always reinstall live things? Never? Or what? |
33 |
> |
34 |
> * How are live ebuilds selected by the package manager? |
35 |
|
36 |
How are reinstalls handled for -9999 ebuilds now? I wouldn't think |
37 |
it would need to change. You'd have to unmask the live ebuild, then it |
38 |
would only be reinstalled if you used --emptytree or specifically asked |
39 |
for it on the command line. I'm not sure this preN+1 thing makes |
40 |
sense. If a user wants to automatically update a live ebuild every |
41 |
week, etc, they need to learn how to use cron. :P |
42 |
|
43 |
If a dev wants to force a reinstall because of ebuild or patch changes |
44 |
or whatever, they should still be able to use -rX as usual. |
45 |
|
46 |
> A lot of projects work like this: |
47 |
> |
48 |
> * trunk/ is current development, and is ahead of any release. |
49 |
> |
50 |
> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is |
51 |
> equal to or ahead of any 0.26 release. |
52 |
> |
53 |
> How does your proposal handle this? |
54 |
|
55 |
I'm guessing the dev would need to change 0.26.live to 0.26.1.live when |
56 |
0.26 was released. I already need to do this with my live ebuilds. Of |
57 |
course, with some projects you never know if the next version will be |
58 |
0.26.1, 0.27, or 0.3, or 1.0... |
59 |
|
60 |
As for an ebuild tracking trunk, I guess we're back to -9999.live. ;P |
61 |
|
62 |
|
63 |
-- |
64 |
gcc-porting, by design, by neglect |
65 |
treecleaner, for a fact or just for effect |
66 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |