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 61D211382C5 for ; Tue, 15 May 2018 09:32:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9A01EE0930; Tue, 15 May 2018 09:32:32 +0000 (UTC) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 39DA9E08DA for ; Tue, 15 May 2018 09:32:31 +0000 (UTC) Received: by mail-ot0-x229.google.com with SMTP id 77-v6so17662266otd.4 for ; Tue, 15 May 2018 02:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vanvoorden-be.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DDMZ+EMIoS6QItrJeUjFSz9NQOEVQXBZNyfoTuiG2VU=; b=mGJAMxO0R37k/EbBrVM0v99MNvYCihYP75cdEVwxArjf0KREfw7VMi5G1viAyT/KXT g+YtWzwV+fTpfwTVoM2SVvsEPUPFW2p/4cxlN3mjMNBa3w6imGZj6FwtwDm8HAz7oIvN 7XZ7oJz/D1KWQbMsg4lRRQCU4CHlxO5qLJ6a5ayEZDVz1zB/61UMq6DP1B5VlHX1fiUY Y5qp2og/xjqIDexk6Qq2egN2DDHipWrfkJx2AP8H5tfrQmyx8KXAD/xZXjf+wlrJPg7R jwfsTgscw8+qSfeFuuJHJHO1XjMJoF8LxkRzYOhM2SeYDeV3kHQDWd+jF3ZxOBnixwGc CJzg== 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; bh=DDMZ+EMIoS6QItrJeUjFSz9NQOEVQXBZNyfoTuiG2VU=; b=L6NYWd04iKNLjY1F73SDu3xu+uMXMVQ9HK2w04pAlZaEUAAdI2v8r89S6tdmH88bHp PjW+vehbS+HT9ZT1Yw8jY7DH6EnjWevI5Sq9x+kwUjNqJw+SZDmfQfMld+oyJ2YSYYV2 m933+L/BBIm43rz+pGVAz2XYX/woLfiCifMDlVz6Dhp3wAoNrUr+7HEeCEPdkwqHToUN KYksfl3FsudpqMCsWAv5f/+hLlZkEteW+c6MtkNlQqc+CmCqcaokZ6yX5KdouEM9MNf9 c/QLQ8j8g9W1fWiuXYp6kbIRh/P2WDiR0bUHJtOVTVlN/0uplwALlVrWxQj+CTt7YNl/ lrSQ== X-Gm-Message-State: ALKqPwf9jF37v3BWr6efLrGppZc82uJgkbgE4M1UjFSO3Mg1529Cm/Ah 8leba7+hRkbQ7zILBDszKvliCcU63E4xrBkiFKvKsgY+JNU= X-Google-Smtp-Source: AB8JxZoPN9I70zE2c8pYFQ+At9lV2ZIeLqjsxwcPDyjov5aVg+kig/qS0LS2pY+9NpEmSVOGpUZ6i/X8nNRCZPlJ9Zc= X-Received: by 2002:a9d:115d:: with SMTP id p29-v6mr10339614otp.390.1526376750630; Tue, 15 May 2018 02:32:30 -0700 (PDT) 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 Received: by 2002:a9d:c66:0:0:0:0:0 with HTTP; Tue, 15 May 2018 02:32:30 -0700 (PDT) In-Reply-To: <2532421.f3YmpD0exa@gump> References: <2532421.f3YmpD0exa@gump> From: Mathy Vanvoorden Date: Tue, 15 May 2018 11:32:30 +0200 Message-ID: Subject: Re: [gentoo-dev] [RFC] multiversion ebuilds To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="00000000000003dd99056c3b4815" X-Archives-Salt: 3f93b16b-6a9b-4680-801a-82eddb892d27 X-Archives-Hash: 18fe303ebb6748d98ed22f3ebd574408 --00000000000003dd99056c3b4815 Content-Type: text/plain; charset="UTF-8" 2018-05-12 14:20 GMT+02:00 Gerion Entrup : 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 ) > ``` > I like the idea of multiversion ebuilds but why would you complicate the process by putting it in a variable? Why not just use symlinks and have the following: foobar/foobar-1.x foobar/foobar-1.1.ebuild -> foobar-1.x foobar/foobar-1.2.ebuild -> foobar-1.x foobar/foobar-2.x foobar/foobar-2.1.ebuild -> foobar-2.x It would result in the same outcome but it seems to me that a lot less work (almost none?) is needed to implement it. Benefits compared to your suggestion: * you don't need to add the extra VERSIONS variable and related logic * you don't need the set of rules * you can have multiple multiversioned ebuilds per package I'm not sure if adding the foobar-1.x file is allowed by portage. You would still need logic like this for the keywording: ``` > if [[ ${PV} == "3.1" ]] ; then > KEYWORDS="~amd64 ~x86" > else > KEYWORDS="amd64 x86" > fi > ``` > br, Mathy --00000000000003dd99056c3b4815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -05-12 14:20 GMT+02:00 Gerion Entrup <gerion.entrup@flump.de><= /span>:

just an idea for now. But wha= t you think about multiversion ebuilds?
Technically this could be realized with the following line in the ebuild it= self:
```
VERSIONS=3D( 3.0.11 3.0.12 3.1 )
```
=C2=A0
I like the idea of multiversi= on ebuilds but why would you complicate the process by putting it in a vari= able? Why not just use symlinks and have the following:

f= oobar/foobar-1.x
foobar/foobar-1.1.ebuild -> foobar-1.x
foobar/foobar-1.2.ebuild -> foobar-1.x
foobar/= foobar-2.x
foobar/foobar-2.1.ebuild -> foobar-2.x

<= /div>
It would result in the same outcome but it seems to me that a lot= less work (almost none?) is needed to implement it.

Benefits compar= ed to your suggestion:
* you don't need to add the extra VERSIONS va= riable and related logic
* you don't need the set of rule= s
* you can have multiple multiversioned ebuilds per package<= br>

I'm not sure if adding the foobar-1.x file is allowed= by portage.

You would still need logic like this for the= keywording:

```
if [[ ${PV} =3D=3D "3.1" ]] ; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 KEYWORDS=3D"~amd64 ~x86"
else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 KEYWORDS=3D"amd64 x86"
fi
```

br,
Mathy
<= /div>
--00000000000003dd99056c3b4815--