| 1 |
Am Samstag, 12. Mai 2018, 16:21:26 CEST schrieb Ulrich Mueller: |
| 2 |
> >>>>> On Sat, 12 May 2018, Gerion Entrup wrote: |
| 3 |
> |
| 4 |
> > just an idea for now. But what you think about multiversion ebuilds? |
| 5 |
> > Technically this could be realized with the following line in the |
| 6 |
> > ebuild itself: |
| 7 |
> > ``` |
| 8 |
> > VERSIONS=( 3.0.11 3.0.12 3.1 ) |
| 9 |
> > ``` |
| 10 |
> |
| 11 |
> > [...] |
| 12 |
> |
| 13 |
> > The advantages of this idea I see are: |
| 14 |
> > - Ebuilds are written in a multiversion manner anyway, and then get |
| 15 |
> > copied (or linked?), so it can be made explicit. |
| 16 |
> > - The diffs between different versions of ebuilds and the commit |
| 17 |
> > history are way more readable. |
| 18 |
> |
| 19 |
> That depends on the options you specify for git diff (e.g., |
| 20 |
> --find-renames, --find-copies, or --find-copies-harder). |
| 21 |
This does not apply to the online diffs (see e.g. [1]). I assume that most users don't have |
| 22 |
the git repository checked out. |
| 23 |
|
| 24 |
> |
| 25 |
> > - The size of the tree reduces. |
| 26 |
> |
| 27 |
> I very much doubt that (or at least it remains to be proven). |
| 28 |
> |
| 29 |
> Currently, when an ebuild is copied for a version bump, it will reuse |
| 30 |
> the same blob in the Git repository. With the scheme above, you would |
| 31 |
> have to modify the ebuild, which would add a new blob for every |
| 32 |
> version bump. |
| 33 |
You are right, I've not thought about that. However, this is only true for |
| 34 |
the repository not for the rsync copy most(?) users have and not for a checkout. |
| 35 |
|
| 36 |
Gerion |
| 37 |
|
| 38 |
[1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9397ab8d48feb4b1360be614da35fa2faae44d9 |
Archives