Sent from an iPhone, sorry for the HTML...
> On Jul 22, 2014, at 6:44 PM, Tom Wijsman <tom...@gentoo.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 22 Jul 2014 09:53:49 -0400
> Ian Stakenvicius <a...@gentoo.org> wrote:
>
>> Using ${PVR} to detect how portage should update things
>> would be asking for trouble, imo.
>
> This entire sub thread reads like a dynamic dependencies alternative in
> disguise, the difference lies in an increase of the level of control
> and in the place where this then gets reimplemented.
>
> The increase of control comes from the maintainer being able to decide
> whether the dependencies in the vdb are updated or not; however, this
> gives rise to a mindset where you consider this level of control for
> other variables as well (which syntax we'll [ab]use for that?) as well
> as end up with more ebuilds for the sake of updating vdb dependencies.
>
> Using an extension like -rX.Y seems odd; at the very least, I think an
> incremental variable or something along that line in the ebuild would
> work better. This allows for array usage like VERSION[dependencies]=1,
> thus allowing other variables to be dynamic as well; you compare that
> number against the one in the vdb, bingo...
>
> Or is it just a figment?
>
> Please think a design through and don't take a cheap shot with -rX.Y.
>
The thing about -rX.Y is that it allows this new-dynamic-deps thing to act like
a regular rev bump to any PM that doesn't bother to implement it (or dynamic
deps for that matter). Instant backwards-compatibility is a handy feature.
