| 1 |
hasufell <hasufell@g.o> wrote: |
| 2 |
> Ulrich Mueller: |
| 3 |
>> |
| 4 |
>> I wonder if it wouldn't be saner to leave our revision syntax |
| 5 |
>> untouched. |
| 6 |
|
| 7 |
As already mentioned, -r1.1 is only one of several possible ways |
| 8 |
how to achieve the same aim; I am not speaking in favour for a |
| 9 |
particular method. |
| 10 |
The -r1.1 method has the advantage of being simple and transparent |
| 11 |
to the user and developer. Other approaches have other advantages: |
| 12 |
|
| 13 |
>> Instead, one could introduce a variable INSTALL_VERSION that would |
| 14 |
|
| 15 |
(It would have to be a variable stored in the metadata/ cache |
| 16 |
and thus also would only work with a new API, but these are only |
| 17 |
technical details.) |
| 18 |
|
| 19 |
>> default to ${PVR} but could be set to the version of a previous ebuild |
| 20 |
>> instead. The PM could compare it against INSTALL_VERSION in the VDB |
| 21 |
>> and skip build and installation if versions match. |
| 22 |
|
| 23 |
It should be a list and have empty default (*never* including the |
| 24 |
version itself), but these are also technical details. |
| 25 |
This solution would have the advantage that you could specify |
| 26 |
*full* versions and thus have even more fine-grained control when |
| 27 |
recompilations are necessary. One could also allow specify version |
| 28 |
ranges, slots, overlays, etc., perhaps even make the behaviour |
| 29 |
dependent of USE-flags, as you already mentioned, all |
| 30 |
similarl to current DEPEND syntax. |
| 31 |
|
| 32 |
The disadvantage is that it is slightly more work than -r1.1, |
| 33 |
less transparent, and easily overlooked to remove for a version bump, |
| 34 |
causing issues like these: |
| 35 |
|
| 36 |
> It will probably also cause confusion for comaintainers and |
| 37 |
> collaborators, especially when INSTALL_VERSION points to a version that |
| 38 |
> has already been removed. |
Archives