1 |
Hi, |
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 ebuild itself: |
5 |
``` |
6 |
VERSIONS=( 3.0.11 3.0.12 3.1 ) |
7 |
``` |
8 |
|
9 |
and the filename without version: |
10 |
<dev-category>/<package-name>/<package-name>.ebuild |
11 |
|
12 |
together with this set of rules: |
13 |
1. If there is an ebuild with had a version in its name, this ebuild is preferred. |
14 |
e.g. is a tree consists of "foobar/foobar-1.1.ebuild" and "foobar/foobar.ebuild" for version 1.1 the specific ebuild is taken. |
15 |
2. If the ebuild has the variable VERSIONS specified but also a version in its name, the version in its name is taken. |
16 |
3. There can be only one multiversioned ebuild per package. |
17 |
|
18 |
Different version keywording can be done as before: |
19 |
``` |
20 |
if [[ ${PV} == "3.1" ]] ; then |
21 |
KEYWORDS="~amd64 ~x86" |
22 |
else |
23 |
KEYWORDS="amd64 x86" |
24 |
fi |
25 |
``` |
26 |
|
27 |
The resolution of versions can be done as before, with the difference that one ebuild can represent multiple versions. |
28 |
|
29 |
The "ebuild" tool needs some adjustments. Maybe it tries to download and build all version per default and has an additional flag to specify a single version. |
30 |
|
31 |
The advantages of this idea I see are: |
32 |
- Ebuilds are written in a multiversion manner anyway, and then get copied (or linked?), so it can be made explicit. |
33 |
- The diffs between different versions of ebuilds and the commit history are way more readable. |
34 |
- The size of the tree reduces. |
35 |
|
36 |
Regards, |
37 |
Gerion |