1 |
Steven J. Long <slong@××××××××××××××××××.uk> wrote: |
2 |
>> |
3 |
>> > It will probably also cause confusion for comaintainers and |
4 |
>> > collaborators, especially when INSTALL_VERSION points to a version |
5 |
>> > that has already been removed. |
6 |
> |
7 |
> So use another name that can't be confused. |
8 |
|
9 |
Perhaps there is a misunderstanding: I did not understand that the |
10 |
confusion is caused by the name, but by the lack of information |
11 |
about its entries: |
12 |
|
13 |
For instance, if you bump a version, you must never forget to |
14 |
check whether this variable needs to be updated. |
15 |
Moreover, if you want to update that variable, you should |
16 |
understand precisely why which version is listed here |
17 |
in order to decide whether a recompile from that version |
18 |
might be needed with the current bump or not. |
19 |
This decision is not necessarily easy if the corresponding |
20 |
referred ebuilds are already in the CVS attic. |
21 |
|
22 |
Of course, if in doubt, it is a safe strategy to always |
23 |
remove that variable (it can only cause redundant compilation, |
24 |
while it can be fatal if you leave a version falsely). |
25 |
|
26 |
Therefore, an automatism to "forget" this variable automatically |
27 |
if not changed would be preferrable, but one would need a mechanism |
28 |
for this (I have only some strange ideas for such a mechanisms: |
29 |
One could encode the current ebuild version into the name of |
30 |
that variable; or one could require that the current version |
31 |
is the first entry in this variable [although, semanatically, |
32 |
it is ignored and just serves as a "proof" that the ebuild |
33 |
maintainer checked that variable]). |