From owner-freebsd-ports@FreeBSD.ORG Fri Apr 1 05:02:05 2011 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 081AC1065C72; Fri, 1 Apr 2011 05:02:05 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC268FC1C; Fri, 1 Apr 2011 05:02:04 +0000 (UTC) Received: by iyj12 with SMTP id 12so3952696iyj.13 for ; Thu, 31 Mar 2011 22:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=R9gJIi4ulN3sa0g5W+mTTuatSGQZ9suRdtFYolyHOAs=; b=kae76WA8V08k39L+IZUWj2CFTsBJW9ZvpPnecgmCjCl9wj20sJrrOVUcfV7A3YJE6q hNCeNbTOqtq1C6C3/B+4fl9I7i/BZtbNANNtT7N0CF2I4dF/JTr9FcF2iae3RrEF1qqC uNw5n5zl5Ez9h+JaeUU9dtfmcMs5i3d37IumU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=nlTSO8hDmd0QejBZe2Qxyx5igLg1FI0JNX5PmFD6awQL1EAxE8GAyj624Rw7X37P9l jA6x0ULRNymczSVWij+B1GgspdFzsR8prtAJnKjO9AS/tE3AKWH38jCmOlgUAJNovus3 E2oqnMUrpVR/c58WThLLYQ6fesXLrQ/VWcvS8= Received: by 10.231.0.95 with SMTP id 31mr3520306iba.34.1301634124111; Thu, 31 Mar 2011 22:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.174.207 with HTTP; Thu, 31 Mar 2011 22:01:44 -0700 (PDT) In-Reply-To: References: From: Baptiste Daroussin Date: Fri, 1 Apr 2011 05:01:44 +0000 Message-ID: To: Eitan Adler Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Ports Subject: Re: Removing Cruft from the ports tree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 05:02:05 -0000 2011/4/1 Eitan Adler : > Hi, > > =A0 =A0I=92m been working recently on a series of PRs that called =93Reap= er > of the Dead=94 PRs. I have been going through the various build files we > have (for source, docs, and especially ports) and attempting to remove > dead code, old cruft, and unneeded checks. Some examples include > ports/155543, ports/155511, ports/154395, conf/155737, and > conf/155738. My goal has been twofold: making it easier to understand > what is going on, and speeding up the process without requiring > significant change. > > =A0 =A0One of the features that has given us the most trouble has been > the options framework for ports. We automatically test ports using the > default options, but we are unable to perform automated using every > combination of options. A port with just four options has sixteen > possible configurations, and some ports have more than that. Even > supporting one option might double the number of things to test. > > =A0 =A0However some ports rely on specific configurations of options of > other ports. In order to deal with this mess we have come up with a > hack: slave ports. We have entire ports that are designed just to > change the default options for other ports. This requires a > non-trivial amount of code on the bsd.*.mk files to support. > > =A0 =A0Automated configuration is not the only thing that has caused us > trouble in the past. We routinely have to do deal with questions from > inexperienced users on questions@ and ports@ details problems with > non-standard configurations. Many times the solution to a ports > related problem is flipping a bit in the options file. > > =A0 =A0I propose removing the options systems entirely. While it does > serve a small purpose of allowing customization for some end users, I > believe the flaws outweigh the benefits. Removing the options > framework would enable us to remove over 500 lines of expensive code > from the ports system. Not only that but because maintainers would be > able to choose the best possible configuration for the their port > users would no longer have to mess around. > > =A0 =A0While I understand there might some minor part of the community > that has a sentimental attachment to the blue-on-gray-on-blue > configuration, and still others want to prematurely optimize, a simple > workaround could be implemented. We can allow users to add their own > ./configure arguments to the makefile. This serves the needs of the > community while allowing us to deal with a simpler and more reliable > ports system. > > =A0 =A0Feel free to express your thoughts here. I would like to get this > hashed out now so the process could occur on a later date(1). > > -- > Eitan Adler > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > Removing the option framework is an option if it is replaced, by something equivalent, I have proposed http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/152568 for example but it needs time to be reviewed by portmgr. This new implementation of option is more consistent and cleaner. The slave ports is not a solution only to make sure we have a port with a given option set, but it is also a way to avoir code duplication (php for exemple). pkgng can register this options passed to a port to an installed package, along with my option framework proposal, it would allow us to be able to check the configuration of a given port from the port infrastructure. My 2c, Bapt