From owner-svn-ports-all@freebsd.org Wed Nov 13 11:47:30 2019 Return-Path: Delivered-To: svn-ports-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EAC531AEB6C; Wed, 13 Nov 2019 11:47:30 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CjXL5w75z3R88; Wed, 13 Nov 2019 11:47:30 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id C4486C864; Wed, 13 Nov 2019 11:47:30 +0000 (UTC) Date: Wed, 13 Nov 2019 11:47:30 +0000 From: Alexey Dokuchaev To: Pietro Cerutti Cc: Tobias Kortkamp , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r517341 - head/x11-wm/e16 Message-ID: <20191113114730.GA51261@FreeBSD.org> References: <201911121700.xACH0fpg045907@repo.freebsd.org> <20191113092534.GA61113@urd.tobik.me> <20191113093405.GB34207@FreeBSD.org> <20191113105755.cniyccipokqjehjr@ptrcrt.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191113105755.cniyccipokqjehjr@ptrcrt.ch> User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 11:47:31 -0000 On Wed, Nov 13, 2019 at 10:57:55AM +0000, Pietro Cerutti wrote: > On Nov 13 2019, 09:34 UTC, Alexey Dokuchaev wrote: > ... > >The entire "rework OPTIONS" code is a mess and should be fixed for > >good. Perhaps Pietro might want to find an extra pair of eyes to review > >his work prior to committing, or at leaset rehash > >/usr/ports/Mk/bsd.options.mk. > > I'm not exactly sure which part of the OPTIONS you find a "mess", and > even less sure how you'd fix it. I haven't found a more direct way to > specify logical dependecies between two RADIO groups, if that's what > you don't like. OK, now, after you've mentioned dependencies between two RADIO groups, it starts to make more sense (albeit I still get lost in those IGNORE's and their reasons; IMPLIES/PREVENTS would be more clear). Regardless, it would be nice to have this explained in the commit log instead of vague and useless "rework OPTIONS". That said, resulting complexity and poor readability often indicate an overengineered solution. Not that I'm implying or insisting on taking any action, but perhaps two codependent RADIO groups is a little too much? :-) ./danfe