On Wed, May 16, 2018 at 2:38 AM, Michał Górny <mgo...@gentoo.org> wrote:
> W dniu sob, 12.05.2018 o godzinie 14∶20 +0200, użytkownik Gerion Entrup
> napisał:
>> Hi,
>>
>> just an idea for now. But what you think about multiversion ebuilds?
>> Technically this could be realized with the following line in the ebuild
>> itself:
>> ```
>> VERSIONS=( 3.0.11 3.0.12 3.1 )
>> ```
>>
>> and the filename without version:
>> <dev-category>/<package-name>/<package-name>.ebuild
>>
>> together with this set of rules:
>> 1. If there is an ebuild with had a version in its name, this ebuild is
>> preferred.
>> 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.
>> 2. If the ebuild has the variable VERSIONS specified but also a version in
>> its name, the version in its name is taken.
>> 3. There can be only one multiversioned ebuild per package.
>>
>> Different version keywording can be done as before:
>> ```
>> if [[ ${PV} == "3.1" ]] ; then
>> KEYWORDS="~amd64 ~x86"
>> else
>> KEYWORDS="amd64 x86"
>> fi
>> ```
>>
>> The resolution of versions can be done as before, with the difference that
>> one ebuild can represent multiple versions.
>>
>> 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.
>>
>> The advantages of this idea I see are:
>> - Ebuilds are written in a multiversion manner anyway, and then get copied
>> (or linked?), so it can be made explicit.
>> - The diffs between different versions of ebuilds and the commit history are
>> way more readable.
>> - The size of the tree reduces.
>>
>
> In my opinion, this puts more effort into inventing a problem than
> solving one. In order to consider a particular idea thouroughly, you
> should also consider potential disadvantages, rather than focusing
> purely on advantages as you see them.
>
> While one might think that this will help developers, it is going to be
> a maintenance nightmare. Just compare the workflow.
>
> Currently, adding a patch affecting runtime involves copying the ebuild,
> and applying the patch. Later on, the old revision is just removed.
> With your solution, you need to adjust VERSIONS, add conditional; later
> on, you need to adjust VERSIONS, find all conditionals, remove them.
> Not only it involves more work but also increases the risk of accidental
> breakage.
>
> The arch team work is going to become a nightmare. Currently, they just
> use 'ekeyword' tool to mass-edit ebuilds. With your solution, they're
> now have to find the correct conditional (or add one), and update
> keywords there. I can already imagine monsters like:
>
> if pv1; then
> KEYWORDS="~amd64"
> elif pv2; then
> KEYWORDS="amd64 ~arm64 x86"
> elif pv3; then
> KEYWORDS="~amd64 ~arm64 ~x86"
> elif pv4; then
> KEYWORDS="amd64 ~arm64 ~x86"
> fi
>
Instead of VERSIONS=( 3.0.11 3.0.12 3.1 ) use KEYWORD_AMD64=( 3.0.11
3.0.12 ~3.1 ).
This would require a variable per arch. It would be possible to create
another structure to contain *these* in some way if having multiple
variables is something that should be avoided at all costs.
Cheers,
R0b0t1
