1 |
"Marijn Schouten (hkBst)" <hkBst@g.o> wrote: |
2 |
|
3 |
> Marius Mauch wrote: |
4 |
|
5 |
> > "Marijn Schouten (hkBst)" <hkBst@g.o> wrote: |
6 |
|
7 |
> >> Marius Mauch wrote: |
8 |
|
9 |
> >>>>> I don't really see how making PV not read-only is any easier |
10 |
> >>>>> than using MY_PV. Did you expect changing PV to magically |
11 |
> >>>>> change P, PVR and PF too? |
12 |
|
13 |
> >>>> If we can agree to have those values writable we could define a |
14 |
> >>>> function that will handle resetting all those too. |
15 |
|
16 |
> >>> Not going to happen. These variables are used internally by |
17 |
> >>> portage in various ways, and making their content inconsistent |
18 |
> >>> with the version in the filename is likely to cause subtle bugs |
19 |
> >>> and/or weird behavior. Besides, you've yet to explain the benefit |
20 |
> >>> of it, short of avoiding a simple replace operation in an ebuild, |
21 |
> >>> and the given use case isn't all that common anyway. |
22 |
|
23 |
> >> Why can't portage use its own variables and export these with an |
24 |
> >> initial value but not use them further? |
25 |
|
26 |
> > Because there is no need to create even more variables when there is |
27 |
> > absolutely no benefit. |
28 |
|
29 |
> The benefit is being able to automatically reversion an ebuild. |
30 |
> Reversioning may not be necessary very often, but it's annoying when |
31 |
> it is and there is no good reason that it should. There is no benefit |
32 |
> in keeping the version variables read-only. |
33 |
|
34 |
What is so hard about using MY_PV that you want portage to change how |
35 |
it uses versioning internally? It's one assignment and a sed. |
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 |