1 |
Ciaran McCreesh wrote: |
2 |
|
3 |
> On Fri, 13 Jun 2008 10:43:39 +0200 |
4 |
> Luca Barbato <lu_zero@g.o> wrote: |
5 |
>> Ciaran McCreesh wrote: |
6 |
>> > On Thu, 12 Jun 2008 21:40:28 +0200 |
7 |
>> > Luca Barbato <lu_zero@g.o> wrote: |
8 |
>> >>> * ordering for _pre is wrong. |
9 |
>> >> hm? |
10 |
>> > |
11 |
>> > foo-0.26-live would become foo-0.26_pre1, which would be < 0.26. |
12 |
>> > This is clearly wrong. |
13 |
>> |
14 |
>> No, it is correct and what you want. Upstream is aiming for 0.26, |
15 |
>> once 0.26 gets in portage you want to update to the release. |
16 |
> |
17 |
> A lot of projects work like this: |
18 |
> |
19 |
> * trunk/ is current development, and is ahead of any release. |
20 |
> |
21 |
> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is |
22 |
> equal to or ahead of any 0.26 release. |
23 |
> |
24 |
> How does your proposal handle this? |
25 |
> |
26 |
>> >>> * How are you planning to handle reinstalls? Should installing |
27 |
>> >>> world always reinstall live things? Never? Or what? |
28 |
>> >> depends on the other ebuilds |
29 |
>> > |
30 |
>> > More specifically? |
31 |
>> |
32 |
>> the live ebuild act as template for a autogenerated _pre, if there is |
33 |
>> something higher than _pre that one will be picked. |
34 |
> |
35 |
> So you install foo-1.2-live. The package manager installs this as |
36 |
> foo-1.2_pre1. Then, foo-1.2-live becomes foo-1.2_pre2. |
37 |
> |
38 |
> Which has two issues: |
39 |
> |
40 |
> * It means whenever you install foo-1.2-live, there will always be a |
41 |
> newer version, and the package manager will always select it for |
42 |
> upgrades. Is this really desired behaviour? |
43 |
> |
44 |
> * It means the package manager somehow has to keep track of what pre to |
45 |
> substitute in. How does it do this? |
46 |
|
47 |
@lu_zero: I don't think we can get away without having the pm know what a |
48 |
live-ebuild exactly is and when to re-install it. |
49 |
(Just in case you were thinking of letting the pm auto-masking/unmasking |
50 |
foo_p${value+1}: this would be hackish and ugly). |
51 |
|
52 |
|
53 |
-- |
54 |
gentoo-dev@l.g.o mailing list |