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