From owner-freebsd-ports@FreeBSD.ORG Wed May 30 21:21:34 2012 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 C28CC1065674; Wed, 30 May 2012 21:21:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1A638FC14; Wed, 30 May 2012 21:21:33 +0000 (UTC) Received: by werg1 with SMTP id g1so225334wer.13 for ; Wed, 30 May 2012 14:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M643usCirnvs3LTKthyxtZY42oxoFQQmRnvNsZ/xsTU=; b=QWaGDpgg5jR4d53Q2qSpc9R1NWSD75VUyY9407D7WAxgN13DA4xlos+bzJl5i/aBtK 1qXwdWESShuPz5RM4RCL03toyjo/MMwQ6a0ukEQl19e6GPBQnfslYkP8lIQyeibKAFzd IPD3FLd2CN1k9rRlLyXbzD0Nlrk1M6FdT9zzrql4jLgoVuvewRc35Gcb6nE7b1rPkRAq eebmX8BN2b/kClKC6TI2RE37xQjhC0y7RmsHZjyRwxQbwT0qh8jKsB6ShZvzjdDUiubr u+Zzy0AHai1d8mPd/rc6BWERxP2UPr55ybtRSFpk8+lxU5XOqUWlzIV/Rm5QEPFDNNT9 7V8w== MIME-Version: 1.0 Received: by 10.216.145.13 with SMTP id o13mr11281712wej.95.1338412892954; Wed, 30 May 2012 14:21:32 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Wed, 30 May 2012 14:21:32 -0700 (PDT) In-Reply-To: References: <20120530063334.GD9952@ithaqua.etoilebsd.net> Date: Wed, 30 May 2012 14:21:32 -0700 Message-ID: From: Kevin Oberman To: Alberto Villa Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, Baptiste Daroussin Subject: Re: Options name, descriptions and consistency 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: Wed, 30 May 2012 21:21:34 -0000 On Wed, May 30, 2012 at 1:46 PM, Alberto Villa wrote: > On Wed, May 30, 2012 at 8:33 AM, Baptiste Daroussin wrote: >> On of the reasons of bsd.options.desc.mk is to be able to share common options >> and descriptions, to have better consistency between ports and to have general >> meaning descriptions that make more sense, has anyone can improve the >> description of an option. > > While I really like what bsd.options.desc.mk is supposed to do, I > would like to recommend to any committer/maintainer (and I will > personally submit a patch for the soon-to-come documentation and for > the file itself) to think before always relying on on default option > descriptions. > > Sometimes just saying "Enable XXX support" doesn't mean anything to > the user, and a more explanatory text would be far better, explaining > maybe what feature one is about to enable instead of just what he is > going to depend on. > > So, please, do not hesitate to redefine option descriptions for your > ports if you feel you can add more information for the port specific > case. +1 Ports in multimedia are a perfect example of this problem. Many ports have dozens of options. While some (like enabling codecs of muxers) are either obvious or easy to ind out about in Wikipedia or by googling, others can be quite obscure. The short line in options really is little or no help for "Enable VPFRE support". Even in simpler ports, it is hard to know the effect of selecting an option in the particular case of port, especially when it is sometimes not obvious what an option has to do with a port. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com