"Marijn Schouten (hkBst)" <hkBst@g.o> wrote:

> Marius Mauch wrote:

> > "Marijn Schouten (hkBst)" <hkBst@g.o> wrote:

> >> Marius Mauch wrote:

> >>>>> I don't really see how making PV not read-only is any easier
> >>>>> than using MY_PV. Did you expect changing PV to magically
> >>>>> change P, PVR and PF too?

> >>>> If we can agree to have those values writable we could define a
> >>>> function that will handle resetting all those too.

> >>> Not going to happen. These variables are used internally by
> >>> portage in various ways, and making their content inconsistent
> >>> with the version in the filename is likely to cause subtle bugs
> >>> and/or weird behavior. Besides, you've yet to explain the benefit
> >>> of it, short of avoiding a simple replace operation in an ebuild,
> >>> and the given use case isn't all that common anyway.

> >> Why can't portage use its own variables and export these with an
> >> initial value but not use them further?

> > Because there is no need to create even more variables when there is
> > absolutely no benefit.

> The benefit is being able to automatically reversion an ebuild.
> Reversioning may not be necessary very often, but it's annoying when
> it is and there is no good reason that it should. There is no benefit
> in keeping the version variables read-only.

What is so hard about using MY_PV that you want portage to change how
it uses versioning internally?  It's one assignment and a sed.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662