From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-84630-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 7EA821382C5
for <garchives@archives.gentoo.org>; Wed, 16 May 2018 23:33:10 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5E7F1E09C6;
Wed, 16 May 2018 23:33:04 +0000 (UTC)
Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id E1CCFE08E5
for <gentoo-dev@lists.gentoo.org>; Wed, 16 May 2018 23:33:03 +0000 (UTC)
Received: by mail-lf0-x241.google.com with SMTP id n18-v6so5945263lfh.10
for <gentoo-dev@lists.gentoo.org>; Wed, 16 May 2018 16:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-transfer-encoding;
bh=JcVKE+q7cfWiVG14WxJbE0afjM2inC6adyfLhnjuAKw=;
b=TZ9hfsMmToLd1d4VmqdcrJnzNPOeUFccHTBx7wEJlKisjvu/afTK3iMS7oeYPBcrrC
nF5SyqDdO5O0QfuH2IaDDi7rF9iwHYgM7C3K69OunM29glkQSUgnsPkusrxTlfRi8faY
+tQwuh35jIMtAObu4oBgq1FN7rSW+tnTzddrmWeoac6NqnPR2Bu9dH3D+OYX12WKgbpl
xAi1XsddJ6yFf/+UuSAcGIA5jVbJaJ8Ruz3XcmG8mWEk2qTNLgsZRaG0TH5bxj3jBLS0
+ZxkCbWVMSiUpqMFFCJFThWqErDEYe3gX2WJ1WL6rGPZT5ZDD0tkfUXOVR0rVtPfFvfV
vZGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-transfer-encoding;
bh=JcVKE+q7cfWiVG14WxJbE0afjM2inC6adyfLhnjuAKw=;
b=EeiLBASP45PWFO8ubXHj/k0TxT5I9X4sG0RQjR7mmFmuDv/csvEpa7tyJJ3PjmBQlu
m1WAjGX2wNIv52sKtvbm1AbwIqaY4zbrF+wTfbRfqN2dM7cFfPGfNO/CjGDQCoH3F+Uz
sNM8UWitDPDOf/Hffi/UMXTBe3+RUpVBZBIZMFncejGvS//3EaL7vfScLy3qUTEXGtRQ
htQePzHzjJC26w7ZUkndY5ZVr1ovKLw7lIM6FhZP7/f3hlOtIg5Wn7rY89RBZ1uz0m45
I9DSWcnBVii54oedTlNmSE/CfgZkjyxcmAwQhe8b9qx321Tu5vCz2jDWF8cteHH1TExb
gmrg==
X-Gm-Message-State: ALKqPwe2HPZUQ8al0lMW7tWxE3amJ7+1ZkUvZQF+R3ZPgXt0KL6v3DZ/
09aZCuvtzB40Fsn33reHI4LmW3o5x4ikmUC+BFX02Q==
X-Google-Smtp-Source: AB8JxZqcSm2ptkIZmHHecZj+lOj0y92mLJXlGRE4nb29+YkkyxTeFROO47TeeyQ+DZ7514erIAuyMRV4Ln+OiJt2rwM=
X-Received: by 2002:a19:c350:: with SMTP id t77-v6mr15539813lff.127.1526513581720;
Wed, 16 May 2018 16:33:01 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.46.156.8 with HTTP; Wed, 16 May 2018 16:33:01 -0700 (PDT)
In-Reply-To: <1526456310.2517.15.camel@gentoo.org>
References: <2532421.f3YmpD0exa@gump> <1526456310.2517.15.camel@gentoo.org>
From: R0b0t1 <r030t1@gmail.com>
Date: Wed, 16 May 2018 18:33:01 -0500
Message-ID: <CAAD4mYhoY+d6SbGwaP01EwwWfXU6pjDBwf34nR2TR9i6OboE+w@mail.gmail.com>
Subject: Re: [gentoo-dev] [RFC] multiversion ebuilds
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 32849b4f-afd7-4eea-bbf9-2ee44ecea238
X-Archives-Hash: c0aef00a33fefb73e5f62905db88a597
On Wed, May 16, 2018 at 2:38 AM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org>=
wrote:
> W dniu sob, 12.05.2018 o godzinie 14=E2=88=B620=E2=80=89+0200, u=C5=BCytk=
ownik Gerion Entrup
> napisa=C5=82:
>> 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=3D( 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/fooba=
r.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} =3D=3D "3.1" ]] ; then
>> KEYWORDS=3D"~amd64 ~x86"
>> else
>> KEYWORDS=3D"amd64 x86"
>> fi
>> ```
>>
>> The resolution of versions can be done as before, with the difference th=
at 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 sing=
le version.
>>
>> The advantages of this idea I see are:
>> - Ebuilds are written in a multiversion manner anyway, and then get copi=
ed (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=3D"~amd64"
> elif pv2; then
> KEYWORDS=3D"amd64 ~arm64 x86"
> elif pv3; then
> KEYWORDS=3D"~amd64 ~arm64 ~x86"
> elif pv4; then
> KEYWORDS=3D"amd64 ~arm64 ~x86"
> fi
>
Instead of VERSIONS=3D( 3.0.11 3.0.12 3.1 ) use KEYWORD_AMD64=3D( 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