From owner-freebsd-ports@FreeBSD.ORG Fri Apr 1 05:00:23 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 91C6F106567C for ; Fri, 1 Apr 2011 05:00:23 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5496B8FC0C for ; Fri, 1 Apr 2011 05:00:20 +0000 (UTC) Received: by qyk27 with SMTP id 27so2475261qyk.13 for ; Thu, 31 Mar 2011 22:00:19 -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:date :message-id:subject:from:to:cc:content-type; bh=CgLifbAEz+KqCyS9kT+ocsMj+5rtdOzNCjqHZll1kPE=; b=knf+gggFJNRlex4jnNVzgG6u9kheJq+u4mI1x5s6ChiRF1AKWO78mUloT09eqsCCCV EGXCN/1Gb1YlKbjSQHKusfRKbx+MF6a6GRH39JJixb2AydRU5Uedk9S6XqQrA2v1yTpg L+7eNgNby+Zj4H6sm834sCDYem0n2k1OLIb58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NP2Qj1ybBCoK6keoYQEs3dWAXJwnCeYrqx/b7j33/drocYiprNdofUap53cT+jf1TO O2FT36EexjmfWGiZS3orKvQcfdpRAifTG00kZepSgMcdfkZanIdRVxLUiXUDqKGwzHHd eNe9wm+byNKfhLzdW/aFjfwT9xAwI+u5Iu69w= MIME-Version: 1.0 Received: by 10.224.9.197 with SMTP id m5mr3020631qam.367.1301632179389; Thu, 31 Mar 2011 21:29:39 -0700 (PDT) Received: by 10.224.67.21 with HTTP; Thu, 31 Mar 2011 21:29:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Apr 2011 00:29:39 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Eitan Adler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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:00:23 -0000 On Thu, Mar 31, 2011 at 11:55 PM, Eitan Adler wrote: > Hi, > > I=E2=80=99m been working recently on a series of PRs that called =E2= =80=9CReaper > of the Dead=E2=80=9D PRs. I have been going through the various build fil= es 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. > > One 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. > > However 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. > > Automated 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. > > --------------------------------------------------------------- > I 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. > > The idea specified above is really very good , because , during =C2=A8make install ...=C2=A8 installations , given a ( non-tested previously ) improper selection sometimes wasting important number of hours because at some point make is producing an error . Sometimes , all of the options may work in the computer of the maintainer o= r tester because some required parts may already be present in their systems = . When a user tries to install such a port into a new computer may lead to failure because those different parts are not present in the new computer . Many times I am encountering that problem , and I wish that the maintainer should test that in a CLEAN computer to encounter the same problem before releasing the subject software . Actually , sometimes the options are really not necessary to ask because to use ( the port under work ) may use it , therefore why to ask about such an option : Instead of asking at least YES or NO , assume worst case as YES , and take actions with respect to this answer , or select the best default and leave the other parts to be completed by the installer with respect to his/her needs . When such an approach is used , ONLY a SINGLE case will be tested with outcome as Success or Failure which correction of problem in that case will be very easy by either removing the optional part or making ready it . As said above , number of possible test cases is an exponential requirement such as ( Number of options to test ) to 2 ( at least when there are only YES or N= O selections ) which requires exponential work to test the possibilities . This is an enormous work requirement . It is obvious that the port maintainers working hard to serve to the community . Instead of increasing their work complexity from linear to exponential ( which is really an unnecessary burden to them ) always we try to eliminate their burdens as much as possible . ------------------------------------------------------------------- > While 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. > > Feel 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 > Thank you very much . Mehmet Erol Sanliturk