From owner-freebsd-ports@freebsd.org Tue Oct 4 06:00:45 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E2ECAF4773 for ; Tue, 4 Oct 2016 06:00:45 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [185.24.122.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF52179E for ; Tue, 4 Oct 2016 06:00:43 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from ultrabook.yoonka.com (188.29.164.46.threembb.co.uk [188.29.164.46]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id u9460dkx060008 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Oct 2016 06:00:41 GMT (envelope-from list1@gjunka.com) X-Authentication-Warning: msa1.earth.yoonka.com: Host 188.29.164.46.threembb.co.uk [188.29.164.46] claimed to be ultrabook.yoonka.com Subject: Re: dependency explosions To: Kurt Jaeger References: <2df71272-7b98-ad73-650a-3ec70beb71d5@freebsd.org> <19d248ae-8919-fdc9-84e8-ff90ae761e6f@gjunka.com> <20161003151148.4860ca1a@curlew.lan> <6d1eb20d-4597-8176-3dbd-661648a6a03c@gjunka.com> <6bb0a476-ed26-1bdd-5ec5-0d6e2adf0b76@FreeBSD.org> <1d50327a-161a-8ec8-9065-fc853ed79a13@gjunka.com> <20161004050958.GD85563@home.opsec.eu> Cc: freebsd-ports@freebsd.org From: Grzegorz Junka Message-ID: Date: Tue, 4 Oct 2016 06:00:32 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161004050958.GD85563@home.opsec.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 06:00:45 -0000 On 04/10/2016 05:09, Kurt Jaeger wrote: > Hi! > >>> Right now, we build packages for >>> [9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets, >>> and we mostly manage to build them over and over again, every two days. >>> Imagine how long it would take to build 320 sets. >> You are trying to take that into extreme to ridicule this as an option. > I think the scenario that "if we had variants, other users would > request other variants" is likely and the number of sets to build > really would explode like that. It's not to ridicule that option. > > The problem is to add code to allow variants is complex and needs > engineering power. > OK, as I mentioned, I was wondering if that would be possible. So, apparently, it would, but would require changes in the code. Forget about other variants that users may want to propose - if they want other variants then they can take it on and maintain. But regarding the changes that would be required to only allow other variants, why do you say it would be complex? Wouldn't that be only a change in pkg so that it can handle dependencies per set properly? Grzegorz