| 1 |
On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman <rich0@g.o> wrote: |
| 2 |
> |
| 3 |
> Doing this would require having portage cache a hash of whatever |
| 4 |
> ebuild it last parsed, and perhaps its eclasses as well if we permit |
| 5 |
> revbump-less eclass changes. Then it would have to check for when |
| 6 |
> these change, perhaps this might be stored in the metadata to speed |
| 7 |
> things up. |
| 8 |
|
| 9 |
I was thinking about this a little more, and the way I'd do it is ID |
| 10 |
whatever ebuild variables we want to allow to be dynamic. Then the |
| 11 |
ebuild would be sourced, and then those variables would be extracted |
| 12 |
and hashed, and that would be treated as the ebuilds dependency state. |
| 13 |
That would be stored in the metadata, and portage would store it in |
| 14 |
vdb when a package is installed. |
| 15 |
|
| 16 |
Then portage could look for any change in state and that would trigger |
| 17 |
a build-less re-merge, which would update vdb with the new state |
| 18 |
(including the new hash). |
| 19 |
|
| 20 |
With this approach you don't need minor revision numbers - any change |
| 21 |
to an ebuild would be considered a minor revision, and when that is |
| 22 |
inappropriate a full revbump should be used instead. |
| 23 |
|
| 24 |
Rich |
Archives