From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 168C91382C5 for ; Wed, 16 May 2018 07:38:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45819E0932; Wed, 16 May 2018 07:38:36 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 CB152E0904 for ; Wed, 16 May 2018 07:38:35 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E0273335C0C; Wed, 16 May 2018 07:38:33 +0000 (UTC) Message-ID: <1526456310.2517.15.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] multiversion ebuilds From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 16 May 2018 09:38:30 +0200 In-Reply-To: <2532421.f3YmpD0exa@gump> References: <2532421.f3YmpD0exa@gump> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 970fb869-57b0-4242-9ce2-f82d49c51c67 X-Archives-Hash: d087edfe93a7359d013bf8799fcf750e 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: > //.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 Basically, any action requiring >1 arch team would involve creating a new version at least temporarily. And I seriously doubt arch teams would really want to spend time collapsing those afterwards. The algorithm you presented might look nice at first. But remember that the developers will now have to do the same thing -- i.e. discover which ebuild should they look at. You're moving for a clear 1 ebuild : 1 file mapping to N ebuilds : 1 file. -- Best regards, Michał Górny