From owner-freebsd-ports@FreeBSD.ORG Fri Apr 1 05:35:11 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 8185B106566B; Fri, 1 Apr 2011 05:35:11 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id D4E9E8FC1A; Fri, 1 Apr 2011 05:35:10 +0000 (UTC) Received: by qyk35 with SMTP id 35so105499qyk.13 for ; Thu, 31 Mar 2011 22:35:10 -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 :content-transfer-encoding; bh=R2zBHpgsy/BBHTdtJH3KuD+LizJPnoQYwoQVgW6ESag=; b=mCS1viP+6AixebSLEAvdATFUqleHTW0Q+U3qejpomlkhDLyGMbr9IthWipptbLWAMz sxaECOdTiCXRnJ+9fUVRgT0R69Zxk6HtCmi/teAewdsqJaHyBZLW6tCBzekkwWHSH5SO p5+cAbN2aWoS5w3R7HF3iPz9mL4NWmteoUyGA= 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:content-transfer-encoding; b=SO/9spzXdwm3SUu+0Igm94FgdRkMqr8Rjo79h+f/ngobqb4k+1YSNNx0FaPPYSqh0A chfmgU5xo4uYy5a3PXIDoYcPPhHyyBX8Xtr0p1c2st1CdxjyAajRiCA+n7Q0FbKzEBWq xcx1pQcUowndetgg3hfUFN8ILUdHckr8largo= MIME-Version: 1.0 Received: by 10.224.200.196 with SMTP id ex4mr2938261qab.5.1301636109272; Thu, 31 Mar 2011 22:35:09 -0700 (PDT) Received: by 10.224.20.19 with HTTP; Thu, 31 Mar 2011 22:35:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Apr 2011 00:35:09 -0500 Message-ID: From: Zhihao Yuan To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Ports , Eitan Adler 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:35:11 -0000 On Thu, Mar 31, 2011 at 11:29 PM, Mehmet Erol Sanliturk wrote: > On Thu, Mar 31, 2011 at 11:55 PM, Eitan Adler wrote: > >> Hi, >> >> =C2=A0 =C2=A0I=E2=80=99m been working recently on a series of PRs that c= alled =E2=80=9CReaper >> of the Dead=E2=80=9D PRs. I have been going through the various build fi= les 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. >> >> =C2=A0 =C2=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. >> >> =C2=A0 =C2=A0However some ports rely on specific configurations of optio= ns 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. >> >> =C2=A0 =C2=A0Automated configuration is not the only thing that has caus= ed 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. >> >> > --------------------------------------------------------------- > > >> =C2=A0 =C2=A0I propose removing the options systems entirely. While it d= oes >> 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=A0=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= or > tester because some required parts may already be present in their system= s . > 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 maintaine= r > 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 t= o > 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 requireme= nt > such as > =C2=A0( Number of options to test ) to 2 ( at least when there are only Y= ES or NO > 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 increasin= g > 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 . > Whenever I adds an option to a port, I tests all of the combinations, with the related dependencies missing or met. Then I ask committers to test them in tinderbox. I think maintainer should take responsible for that, not the options system. Options do make sense. In some cases, one single options can eliminate/add over 50 dependencies, which save/waste all users' time. We maintainers/developers exists to save users' time. Not just the time to build ports! In a world without options, like Archlinux, just check its AUR repository -- one software may have 10 pages of different PKBGUILDs! Options significantly limit the increasing of the different package names. A good example of to make use of options is Gentoo's ebuild system. The USE_* flags are nothing new, but they are standardized. We may need to standardize our WITH_*/WITHOUT_* flags instead of giving a "commonly use flags" instruction. > > ------------------------------------------------------------------- > > >> =C2=A0 =C2=A0While I understand there might some minor part of the commu= nity >> 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. >> >> =C2=A0 =C2=A0Feel free to express your thoughts here. I would like to ge= t this >> hashed out now so the process could occur on a later date(1). >> >> -- >> Eitan Adler >> > > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > 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" > --=20 Zhihao Yuan The best way to predict the future is to invent it.