From owner-freebsd-ports@FreeBSD.ORG Mon May 8 21:35:13 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7476816A402 for ; Mon, 8 May 2006 21:35:13 +0000 (UTC) (envelope-from msid@daemons.gr) Received: from jefferson.hostingzoom.com (jefferson.hostingzoom.com [216.118.117.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB7A843D48 for ; Mon, 8 May 2006 21:35:12 +0000 (GMT) (envelope-from msid@daemons.gr) Received: from [88.218.36.6] (port=63204 helo=localhost) by jefferson.hostingzoom.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FdDNk-0001u1-Ll; Mon, 08 May 2006 16:35:12 -0500 Date: Tue, 9 May 2006 00:35:04 +0300 From: Sideris Michael To: Shaun Amott Message-ID: <20060508213504.GB73976@daemons.gr> References: <20060508200926.GA6005@daemons.gr> <20060508212441.GB767@picobyte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060508212441.GB767@picobyte.net> User-Agent: Mutt/1.4.2.1i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jefferson.hostingzoom.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - daemons.gr X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-ports@freebsd.org Subject: Re: ports structure and improvement suggestions 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: Mon, 08 May 2006 21:35:13 -0000 On Mon, May 08, 2006 at 10:24:41PM +0100, Shaun Amott wrote: > On Mon, May 08, 2006 at 11:09:26PM +0300, Sideris Michael wrote: > > > > I am writing this email in order to "discuss" with you about the current structure of Ports. To tell > > you the truth, it is not really about the structure rather than the way Ports are handled by people. > > I will focus exclusively on building from source since this is the cutting edge really. > > > > First of all, we have a number of ports. Each port has a number of KNOBS along with a number of > > dependencies that come with their own KNOBS as well. So, if we actually want to install one port and > > There are 14583 ports to be exact, as of last night. Out of curiosity, I > wrote a quick script to count the number of ports Makefiles containing > "WITH": clearly not foolproof, but the result it returned was 2238. > > I'm also curious about whether the average user really cares about > OPTIONS. I generally don't care about what OPTIONS are set for ports > installed as dependencies, other than things like WITHOUT_X11 and > WITHOUT_JAVA. The structure of a system is not defined exclusively by the tastes of a single user. Sorry. > > People need to keep one style of configuration. Either use KNOBS exclusively or modify the existing > > Makefiles to include the OPTIONS framework and enforce the maintainers to keep it that way. In the > > first case, we need to solve an additional problem. It is unacceptable, in my opinion, to use an > > application like pkgtools, in order to modify seperately KNOBS for ports. Take for example NetBSD. > > In NetBSD the user defines KNOBS in /etc/make.conf exclusively, that's it. Implementing the approach > > of NetBSD in the first case is ideal. Also, it would be nice to include tools like portupgrade, not > > portupgrade, in the base system. Portsnap was a good start to eliminate cvsup, in a way. A standard > > Some of us like cvsup. :) > > I don't anticipate seeing portupgrade in base any time soon, for the > same reason cvsup was kept out. I do like cvsup. But using a floppy installation for example I need to add cvsup-without-gui as a package in the end of the installation so that when I log in my system I will use it to fetch the ports tree. With portsnap I just log in, fetch it, extract it, done. Easier and faster. > > tool for upgrading the ports is also a nice idea. In the second case now, things tend to be more > > simple. Using something like make config && make config-recursive the user will be able to configure > > ALL ports before installing them. Both solutions are acceptable by me. Just keep it one way or the > > other, not both. > > > > Unfortunately, the OPTIONS framework is somewhat limited in its current > state. One problem is that OPTIONS needs to be defined before including > bsd.port.pre.mk, but then the processing of WITH(OUT)_* variables has to > be done afterwards. For example, www/horde has a huge list of knobs, but > only a handful could be converted to OPTIONS because they set variables > that need to be defined before bsd.port.pre.mk is included. As a > sidenote, I submitted a simple patch to "fix" this some time ago, but it > doesn't appear to have had much interest. :-) > > Another issue is that the framework only includes support for simple > checklists: no submenus, no "radio" controls , etc. There's no > reasonable way - other than spitting out an error message and asking > the user to try again - of dealing with mutually exclusive knobs in > OPTIONS. > > There is also no space for detailed descriptions of what knobs do inside > the OPTIONS dialog. It is often easier to make the user look at the > Makefile for a description and/or print out a message before installing. > > Most of these issues have been discussed on the lists in the past. Maybe I am not an expert regarding ports, but I thought there is a way to convert all ports Makefiles without any problems. Maybe I am wrong.