Re: [gentoo-dev] [RFC] multiversion ebuilds

On Thu, May 17, 2018 at 11:44 AM Gerion Entrup wrote: > 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="1.0 1.1 1.2") can just be copied, > renamed with t

Re: [gentoo-dev] [RFC] multiversion ebuilds

Am Mittwoch, 16. Mai 2018, 09:38:30 CEST schrieb Michał Górny: > 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

Re: [gentoo-dev] [RFC] multiversion ebuilds

On Wed, May 16, 2018 at 2:38 AM, Michał Górny 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 >

Re: [gentoo-dev] [RFC] multiversion ebuilds

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 ) > ``` > > an

Re: [gentoo-dev] [RFC] multiversion ebuilds

> On Wed, 16 May 2018, Ulrich Mueller wrote: > On Wed, 16 May 2018, Paweł Hajdan, wrote: >> I'm wondering: if the main goal would be more code sharing between >> ebuilds, would something like >> >> (essentially per-package ec

Re: [gentoo-dev] [RFC] multiversion ebuilds

> On Wed, 16 May 2018, Paweł Hajdan, wrote: > I'm wondering: if the main goal would be more code sharing between > ebuilds, would something like > > (essentially per-package eclasses) be an option? eblits! /me hides pgpSQ9fZWt

Re: [gentoo-dev] [RFC] multiversion ebuilds

On 12/05/2018 14:20, Gerion Entrup wrote: > 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 I'm

Re: [gentoo-dev] [RFC] multiversion ebuilds

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

Re: [gentoo-dev] [RFC] multiversion ebuilds

On Saturday, May 12, 2018 5:20:30 AM PDT Gerion Entrup wrote: > 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 ) > ``` You may also be interested ch

Re: [gentoo-dev] [RFC] multiversion ebuilds

On Saturday, 12 May 2018 16:36:13 CEST Gerion Entrup wrote: > Am Samstag, 12. Mai 2018, 16:21:26 CEST schrieb Ulrich Mueller: > > > On Sat, 12 May 2018, Gerion Entrup wrote: > > > - The size of the tree reduces. > > > > I very much doubt that (or at least it remains to be proven). > > > > Cur

Re: [gentoo-dev] [RFC] multiversion ebuilds

Am Samstag, 12. Mai 2018, 16:24:00 CEST schrieb R0b0t1: > On Sat, May 12, 2018 at 7:20 AM, Gerion Entrup wrote: > > - The size of the tree reduces. > > > > If this is a big concern you may be able to mount the portage tree > under a compressed loopback filesystem. It may even be worth > consideri

Re: [gentoo-dev] [RFC] multiversion ebuilds

Am Samstag, 12. Mai 2018, 16:21:26 CEST schrieb Ulrich Mueller: > > On Sat, 12 May 2018, Gerion Entrup wrote: > > > 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

Re: [gentoo-dev] [RFC] multiversion ebuilds

On Sat, May 12, 2018 at 7:20 AM, Gerion Entrup wrote: > - The size of the tree reduces. > If this is a big concern you may be able to mount the portage tree under a compressed loopback filesystem. It may even be worth considering that as a recommended-by-handbook default as the benefit for compre

Re: [gentoo-dev] [RFC] multiversion ebuilds

> On Sat, 12 May 2018, Gerion Entrup wrote: > 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 ) > ``` > [...] > The advantages of this idea I see are

Re: [gentoo-dev] [RFC] multiversion ebuilds

Am Samstag, 12. Mai 2018, 15:47:57 CEST schrieb Rich Freeman: > On Sat, May 12, 2018 at 8:20 AM Gerion Entrup > wrote: > > > > Different version keywording can be done as before: > > ``` > > if [[ ${PV} == "3.1" ]] ; then > > KEYWORDS="~amd64 ~x86" > > else > > KEYWORDS="amd64

Re: [gentoo-dev] [RFC] multiversion ebuilds

On Sat, May 12, 2018 at 8:20 AM Gerion Entrup wrote: > Different version keywording can be done as before: > ``` > if [[ ${PV} == "3.1" ]] ; then > KEYWORDS="~amd64 ~x86" > else > KEYWORDS="amd64 x86" > fi > ``` From a readability standpoint I could see this getting out of ha

[gentoo-dev] [RFC] multiversion ebuilds

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 w