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 D2A6F1382C5 for ; Thu, 17 May 2018 15:44:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CA7F5E0A83; Thu, 17 May 2018 15:44:35 +0000 (UTC) Received: from mail.flump.de (unknown [84.200.20.107]) (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 59062E0A5D for ; Thu, 17 May 2018 15:44:34 +0000 (UTC) Received: from falbala.localnet (unknown [130.75.33.21]) by mail.flump.de (Postfix) with ESMTPSA id F3F351811C4 for ; Thu, 17 May 2018 17:45:23 +0200 (CEST) From: Gerion Entrup To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] multiversion ebuilds Date: Thu, 17 May 2018 17:44:46 +0200 Message-ID: <1788997.QyjqdLkaAm@falbala> In-Reply-To: <1526456310.2517.15.camel@gentoo.org> References: <2532421.f3YmpD0exa@gump> <1526456310.2517.15.camel@gentoo.org> 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: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 9474c995-2e50-4a86-bfa7-7ede460a89aa X-Archives-Hash: a3c64b6c300e16c0db940a50f76a537a Am Mittwoch, 16. Mai 2018, 09:38:30 CEST schrieb Micha=C5=82 G=C3=B3rny: > 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, > >=20 > > just an idea for now. But what you think about multiversion ebuilds? > > Technically this could be realized with the following line in the ebuil= d itself: > > ``` > > VERSIONS=3D( 3.0.11 3.0.12 3.1 ) > > ``` > >=20 > > and the filename without version: > > //.ebuild > >=20 > > 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/foob= ar.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. > >=20 > > 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 > > ``` > >=20 > > The resolution of versions can be done as before, with the difference t= hat one ebuild can represent multiple versions. > >=20 > > The "ebuild" tool needs some adjustments. Maybe it tries to download an= d build all version per default and has an additional flag to specify a sin= gle version. > >=20 > > The advantages of this idea I see are: > > - Ebuilds are written in a multiversion manner anyway, and then get cop= ied (or linked?), so it can be made explicit. > > - The diffs between different versions of ebuilds and the commit histor= y are way more readable. > > - The size of the tree reduces. > >=20 >=20 > 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. >=20 > While one might think that this will help developers, it is going to be > a maintenance nightmare. Just compare the workflow. >=20 > Currently, adding a patch affecting runtime involves copying the ebuild, > and applying the patch. Later on, the old revision is just removed.=20 > With your solution, you need to adjust VERSIONS, add conditional; later > on, you need to adjust VERSIONS, find all conditionals, remove them.=20 > Not only it involves more work but also increases the risk of accidental > breakage. I'm not sure, if I understand you correctly, so I try to express myself: If an ebuild (say foobar-1.0.ebuild) needs a patch affecting runtime, the current workflow is to copy the ebuild, add the code that applies the patch and do a revbump (to foobar-1.0-r1.ebuild). The old ebuild remains untouched. With the VERSIONS approach, the VERSIONS need to be adjusted to contain the revbump version as well, and add a conditional that applies only in the revbump version the patch and otherwise not. The VERSIONS approach does not break the old mechanism. So if a patch needs to be applied, the multiversion ebuild (that contains other versions as well, say foobar.ebuild with VERSIONS=3D"1.0 1.1 1.2") can just be copie= d, renamed with the revbump number (to foobar-1.0-r1.ebuild) and completed with the apply line. Once the old versions should be deleted the VERSIONS variable can be adjusted (to VERSIONS=3D"1.1 1.2"). > 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: >=20 > 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 >=20 > 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. You are right, I have not thought about that. Maybe the approach of R0b0t1 would work. > 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. Gerion