1 |
W dniu sob, 12.05.2018 o godzinie 14∶20 +0200, użytkownik Gerion Entrup |
2 |
napisał: |
3 |
> Hi, |
4 |
> |
5 |
> just an idea for now. But what you think about multiversion ebuilds? |
6 |
> Technically this could be realized with the following line in the ebuild itself: |
7 |
> ``` |
8 |
> VERSIONS=( 3.0.11 3.0.12 3.1 ) |
9 |
> ``` |
10 |
> |
11 |
> and the filename without version: |
12 |
> <dev-category>/<package-name>/<package-name>.ebuild |
13 |
> |
14 |
> together with this set of rules: |
15 |
> 1. If there is an ebuild with had a version in its name, this ebuild is preferred. |
16 |
> 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. |
17 |
> 2. If the ebuild has the variable VERSIONS specified but also a version in its name, the version in its name is taken. |
18 |
> 3. There can be only one multiversioned ebuild per package. |
19 |
> |
20 |
> Different version keywording can be done as before: |
21 |
> ``` |
22 |
> if [[ ${PV} == "3.1" ]] ; then |
23 |
> KEYWORDS="~amd64 ~x86" |
24 |
> else |
25 |
> KEYWORDS="amd64 x86" |
26 |
> fi |
27 |
> ``` |
28 |
> |
29 |
> The resolution of versions can be done as before, with the difference that one ebuild can represent multiple versions. |
30 |
> |
31 |
> 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. |
32 |
> |
33 |
> The advantages of this idea I see are: |
34 |
> - Ebuilds are written in a multiversion manner anyway, and then get copied (or linked?), so it can be made explicit. |
35 |
> - The diffs between different versions of ebuilds and the commit history are way more readable. |
36 |
> - The size of the tree reduces. |
37 |
> |
38 |
|
39 |
In my opinion, this puts more effort into inventing a problem than |
40 |
solving one. In order to consider a particular idea thouroughly, you |
41 |
should also consider potential disadvantages, rather than focusing |
42 |
purely on advantages as you see them. |
43 |
|
44 |
While one might think that this will help developers, it is going to be |
45 |
a maintenance nightmare. Just compare the workflow. |
46 |
|
47 |
Currently, adding a patch affecting runtime involves copying the ebuild, |
48 |
and applying the patch. Later on, the old revision is just removed. |
49 |
With your solution, you need to adjust VERSIONS, add conditional; later |
50 |
on, you need to adjust VERSIONS, find all conditionals, remove them. |
51 |
Not only it involves more work but also increases the risk of accidental |
52 |
breakage. |
53 |
|
54 |
The arch team work is going to become a nightmare. Currently, they just |
55 |
use 'ekeyword' tool to mass-edit ebuilds. With your solution, they're |
56 |
now have to find the correct conditional (or add one), and update |
57 |
keywords there. I can already imagine monsters like: |
58 |
|
59 |
if pv1; then |
60 |
KEYWORDS="~amd64" |
61 |
elif pv2; then |
62 |
KEYWORDS="amd64 ~arm64 x86" |
63 |
elif pv3; then |
64 |
KEYWORDS="~amd64 ~arm64 ~x86" |
65 |
elif pv4; then |
66 |
KEYWORDS="amd64 ~arm64 ~x86" |
67 |
fi |
68 |
|
69 |
Basically, any action requiring >1 arch team would involve creating |
70 |
a new version at least temporarily. And I seriously doubt arch teams |
71 |
would really want to spend time collapsing those afterwards. |
72 |
|
73 |
The algorithm you presented might look nice at first. But remember that |
74 |
the developers will now have to do the same thing -- i.e. discover which |
75 |
ebuild should they look at. You're moving for a clear 1 ebuild : 1 file |
76 |
mapping to N ebuilds : 1 file. |
77 |
|
78 |
-- |
79 |
Best regards, |
80 |
Michał Górny |