| 1 |
Michał Górny <mgorny@g.o> wrote: |
| 2 |
>> If this is such a big problem, maybe we should be discussing how to |
| 3 |
>> redesign things to improve it? |
| 4 |
> |
| 5 |
> Like, by not using eclasses and instead inlining all the stuff? |
| 6 |
|
| 7 |
There are other ways. |
| 8 |
|
| 9 |
One way to mitigate the problem might be to require that |
| 10 |
eclasses contain some |
| 11 |
|
| 12 |
# @VERSION: major.minor-revision |
| 13 |
|
| 14 |
line and that the metadata cache of an ebuild contains that version |
| 15 |
number (or at least the major component of it) instead of an md5 sum. |
| 16 |
Then the commiter of the eclass has full control whether a metadata |
| 17 |
regeneration will happen or not: |
| 18 |
|
| 19 |
For trivial changes (see below), the committer simply does not |
| 20 |
increase that version number (or increase only minor-revision), |
| 21 |
and one could agree that a rebuild of the metadata only happens |
| 22 |
if the major version number of an eclass changes. |
| 23 |
|
| 24 |
By "trivial changes" I mean in this connection not only changes |
| 25 |
in comments but also minor changes in functionality or even in |
| 26 |
the API: The only strict requirement is that the major version |
| 27 |
has to increase if the eclass change can induce a change in the |
| 28 |
metadata of some ebuild using it (e.g. if a value printed by |
| 29 |
some function changes which might involve IUSE, REQUIRED_USE, |
| 30 |
DEPEND, ...) |
Archives