| 1 |
Ulrich Mueller: |
| 2 |
>>>>>> On Sun, 27 Jul 2014, Martin Vaeth wrote: |
| 3 |
> |
| 4 |
>> Kent Fredric <kentfredric@×××××.com> wrote: |
| 5 |
>>> -r1.1 weirdness feels like it may cause more problems than it solves. |
| 6 |
> |
| 7 |
>> So far, nobody pointed out any problem which would be caused by -r1.1. |
| 8 |
>> Which is not surprising, since the idea is that -r1.1 cannot be |
| 9 |
>> distinguished from -r2: |
| 10 |
>> It is only a hint to the PM that he *may* shortcut certain phases when |
| 11 |
>> updating from -r1. |
| 12 |
> |
| 13 |
> I wonder if it wouldn't be saner to leave our revision syntax |
| 14 |
> untouched. |
| 15 |
> |
| 16 |
> Instead, one could introduce a variable INSTALL_VERSION that would |
| 17 |
> default to ${PVR} but could be set to the version of a previous ebuild |
| 18 |
> instead. The PM could compare it against INSTALL_VERSION in the VDB |
| 19 |
> and skip build and installation if versions match. |
| 20 |
> |
| 21 |
> Advantages: |
| 22 |
> - Support for the variable could be optional. PMs not supporting it |
| 23 |
> would do a regular revbump instead. |
| 24 |
> - One could even imagine USE-conditional syntax for the variable. |
| 25 |
> |
| 26 |
|
| 27 |
Aren't we putting a lot of trust in ebuild writers here? If any, I'd say |
| 28 |
this should definitely be an optional feature for portage as well and |
| 29 |
default to off. |
| 30 |
|
| 31 |
The only time I would really consider using this would be for the very |
| 32 |
few time-intensive packages I maintain like paraview, rstudio or |
| 33 |
blender. For the rest, it's too much effort. |
| 34 |
|
| 35 |
It will probably also cause confusion for comaintainers and |
| 36 |
collaborators, especially when INSTALL_VERSION points to a version that |
| 37 |
has already been removed. |
Archives