| 1 |
Sent from an iPhone, sorry for the HTML... |
| 2 |
|
| 3 |
> On Jul 22, 2014, at 6:44 PM, Tom Wijsman <TomWij@g.o> wrote: |
| 4 |
> |
| 5 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 6 |
> Hash: SHA1 |
| 7 |
> |
| 8 |
> On Tue, 22 Jul 2014 09:53:49 -0400 |
| 9 |
> Ian Stakenvicius <axs@g.o> wrote: |
| 10 |
> |
| 11 |
>> Using ${PVR} to detect how portage should update things |
| 12 |
>> would be asking for trouble, imo. |
| 13 |
> |
| 14 |
> This entire sub thread reads like a dynamic dependencies alternative in |
| 15 |
> disguise, the difference lies in an increase of the level of control |
| 16 |
> and in the place where this then gets reimplemented. |
| 17 |
> |
| 18 |
> The increase of control comes from the maintainer being able to decide |
| 19 |
> whether the dependencies in the vdb are updated or not; however, this |
| 20 |
> gives rise to a mindset where you consider this level of control for |
| 21 |
> other variables as well (which syntax we'll [ab]use for that?) as well |
| 22 |
> as end up with more ebuilds for the sake of updating vdb dependencies. |
| 23 |
> |
| 24 |
> Using an extension like -rX.Y seems odd; at the very least, I think an |
| 25 |
> incremental variable or something along that line in the ebuild would |
| 26 |
> work better. This allows for array usage like VERSION[dependencies]=1, |
| 27 |
> thus allowing other variables to be dynamic as well; you compare that |
| 28 |
> number against the one in the vdb, bingo... |
| 29 |
> |
| 30 |
> Or is it just a figment? |
| 31 |
> |
| 32 |
> Please think a design through and don't take a cheap shot with -rX.Y. |
| 33 |
> |
| 34 |
|
| 35 |
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. |
Archives