1 |
On Mon, Jul 28, 2014 at 05:49:07AM +0000, Martin Vaeth wrote: |
2 |
> hasufell <hasufell@g.o> wrote: |
3 |
> > Ulrich Mueller: |
4 |
> >> |
5 |
> >> I wonder if it wouldn't be saner to leave our revision syntax |
6 |
> >> untouched. |
7 |
> |
8 |
> As already mentioned, -r1.1 is only one of several possible ways |
9 |
> how to achieve the same aim; I am not speaking in favour for a |
10 |
> particular method. |
11 |
|
12 |
Sure. As dolsen prefix is using it, even if this weren't better done |
13 |
as metadata. |
14 |
|
15 |
> The -r1.1 method has the advantage of being simple and transparent |
16 |
> to the user and developer. Other approaches have other advantages: |
17 |
> |
18 |
> >> Instead, one could introduce a variable INSTALL_VERSION that would |
19 |
> |
20 |
> (It would have to be a variable stored in the metadata/ cache |
21 |
> and thus also would only work with a new API, but these are only |
22 |
> technical details.) |
23 |
|
24 |
Agreed again, there's far too much conflabation of EAPI vs impl round here. |
25 |
Not helped by the obfuscatory troll you've had the mispleasure to encounter. |
26 |
Think of it as an initiation.. ;-) |
27 |
|
28 |
> >> default to ${PVR} but could be set to the version of a previous ebuild |
29 |
> >> instead. The PM could compare it against INSTALL_VERSION in the VDB |
30 |
> >> and skip build and installation if versions match. |
31 |
> |
32 |
> It should be a list and have empty default (*never* including the |
33 |
> version itself), but these are also technical details. |
34 |
> This solution would have the advantage that you could specify |
35 |
> *full* versions and thus have even more fine-grained control when |
36 |
> recompilations are necessary. One could also allow specify version |
37 |
> ranges, slots, overlays, etc., perhaps even make the behaviour |
38 |
> dependent of USE-flags, as you already mentioned, all |
39 |
> similarl to current DEPEND syntax. |
40 |
> |
41 |
> The disadvantage is that it is slightly more work than -r1.1, |
42 |
> less transparent, and easily overlooked to remove for a version bump, |
43 |
> causing issues like these: |
44 |
> |
45 |
> > It will probably also cause confusion for comaintainers and |
46 |
> > collaborators, especially when INSTALL_VERSION points to a version that |
47 |
> > has already been removed. |
48 |
|
49 |
So use another name that can't be confused. Perhaps REPLACES_VERSION, or |
50 |
w/e the primadonna will allow, since we're still feeding him goats.. |
51 |
Perhaps doubt he'll want to pluralise it, in that tedious nu-skool way |
52 |
of his. More likely he'll just use anything we discuss as an excuse |
53 |
for more FUD. |
54 |
|
55 |
Regards, |
56 |
steveL |
57 |
|
58 |
PS: Now you know just why.. |
59 |
-- |
60 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |