| 1 |
>>>>> On Sat, 12 May 2018, Gerion Entrup wrote: |
| 2 |
|
| 3 |
> just an idea for now. But what you think about multiversion ebuilds? |
| 4 |
> Technically this could be realized with the following line in the |
| 5 |
> ebuild itself: |
| 6 |
> ``` |
| 7 |
> VERSIONS=( 3.0.11 3.0.12 3.1 ) |
| 8 |
> ``` |
| 9 |
|
| 10 |
> [...] |
| 11 |
|
| 12 |
> The advantages of this idea I see are: |
| 13 |
> - Ebuilds are written in a multiversion manner anyway, and then get |
| 14 |
> copied (or linked?), so it can be made explicit. |
| 15 |
> - The diffs between different versions of ebuilds and the commit |
| 16 |
> history are way more readable. |
| 17 |
|
| 18 |
That depends on the options you specify for git diff (e.g., |
| 19 |
--find-renames, --find-copies, or --find-copies-harder). |
| 20 |
|
| 21 |
> - The size of the tree reduces. |
| 22 |
|
| 23 |
I very much doubt that (or at least it remains to be proven). |
| 24 |
|
| 25 |
Currently, when an ebuild is copied for a version bump, it will reuse |
| 26 |
the same blob in the Git repository. With the scheme above, you would |
| 27 |
have to modify the ebuild, which would add a new blob for every |
| 28 |
version bump. |
| 29 |
|
| 30 |
Ulrich |
Archives