From owner-freebsd-ports@FreeBSD.ORG Tue May 9 16:37:39 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 2B53216A5C5 for ; Tue, 9 May 2006 16:37:39 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2189043D7D for ; Tue, 9 May 2006 16:37:22 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so1461486nzi for ; Tue, 09 May 2006 09:37:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:organization:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=BhYZc4oMyZK669wEM3/Qmte//kXZ98IANlTjxObiSlmIB5rPgFHLG8cIAqW7k5+Te8LeKMQLZJ/vOzdCc1IqckSCIq0Y/VYsgQeL/W7AJsPi/RINgduCoe6Af1rpmphi1mkaxStqHi/0C9v9ssb2di/s7Vc2lTPJBT/jwuvFNec= Received: by 10.36.90.9 with SMTP id n9mr5276424nzb; Tue, 09 May 2006 09:37:22 -0700 (PDT) Received: from yuanjue.net ( [59.66.138.109]) by mx.gmail.com with ESMTP id 36sm2930084nza.2006.05.09.09.37.18; Tue, 09 May 2006 09:37:21 -0700 (PDT) Organization: Tsinghua UNIV. To: freebsd-ports@freebsd.org Date: Wed, 10 May 2006 00:37:07 +0800 User-Agent: KMail/1.9.1 References: <20060508200926.GA6005@daemons.gr> In-Reply-To: <20060508200926.GA6005@daemons.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605100037.08447.yuanjue@yuanjue.net> From: "Yuan, Jue" Cc: Sideris Michael 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: Tue, 09 May 2006 16:37:47 -0000 Have got a question for the OPTIONS Framework. Since it will putting KNOBS in /etc/make.conf, the problem is: when one port put "WITH_X11=yes" into make.conf, while later another port may put "WITHOUT_X11=yes" into the same file. So when the ports tree are upgraded and building process for these two ports happens, as far as I can see, there are still some difficulties to tell which KNOB is for which port, right? I am not saying it is unresolved. Many solutions I have seen are mentioned here. But it is not what the OPTIONS Framework does automatically ;-) So using the OPTIONS Framework only may not be a complete solution for ports, from this point of view :-) On Tuesday 09 May 2006 04:09, Sideris Michael wrote: > Hello everyone. > > 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 that port has 5 KNOBS, we > end up installing 10 ports with 30 KNOBS. This is all ok. But, there are > some complications. There are two ways of configuring a port. Edit its > Makefile defining the KNOBS you want or if you are lucky enough install a > port that supports the OPTIONS framework. The current situation in the > ports is a mixture of both, which is why it causes all these complications. > > Now, using the first way to configure the ports, is pretty useless. On the > next ports tree update your changes are gone and the ports to be upgraded > are missing your older customizations. You need to define them somewhere so > that you won't lose them. Unfortunately, it is not mentioned in the > handbook that you can place your KNOBS in /etc/make.conf. So, we found a > solution for this. We will be putting our KNOBS in /etc/make.conf and > whenever we can configure a port through the OPTIONS framework we will do > so. Right? Wrong. Consider the example I gave above. The port you want to > install with its 5 KNOBS, is actually 10 ports with 10 KNOBS. So what? > Well, you have to visit 10 different port directories, after you find their > location, go through 10 Makefiles to discover which of these ports can be > configured by adding KNOBS to /etc/make.conf or by using the OPTIONS > framework. And this is somewgar a mild case. There are ports with more than > 20 dependencies and over 50 KNOBS. > > Now, let's consider that somebody knows all these, which are not mentioned > in that clear way through the handbook. He will need 2-5 minutes to > configure his ports. Let me not talk about the average or new user. So, > after you realize how all this works you need to take it a step further. > Upgrading ports and customizing ports seperately(conflicting KNOBS). Let me > explain to you what I mean. Let's say you want to install a port using the > knob WITHOUT_X11=yes. And then you want to install another one with the > previous knob disabled. You need a permanent way to set the knob for the > firt port without affecting other ports. I am aware of one way to do this. > Edit the configuration file that comes with pkgtools, > /usr/local/etc/pkgtools.conf. You will find a section for configuring KNOBS > for each port explicitely. Of course, one you do this, you need to use > portinstall that comes with pkgtools(pkgtools are installed once you > install portupgrade). Using portinstall to install ports takes into account > both the KNOBS in pkgtools.conf and the KNOBS in /etc/make.conf. > > So, this is the optimal way to customize ports by defining KNOBS. Don't > forget though that some ports are configured through the OPTIONS framework > along with the fact that you have to discover the KNOBS for each port and > which ports are configured through the OPTIONS framework. Now, this is both > inefficient and complicated. Unless I am really missing something. It > works, I don't deny that, but, very very complicated and time consuming. In > my opinion, these things need to be solved. > > 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 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. > > To conclude with my email, I would like to thank everyone for taking the > time to read it and please, in case you are planing to reply in order to > propose something or argue back, make sure you have done your homework. I > would like to hear your ideas and comments on the things I mentioned above. > One last thing. Without any intention to advertise anything, I have > creating a shell script, that given a port name as an argument it can find, > or at least try to find, recursively all the dependencies of this port > along with the KNOBS associated with each port and display which of these > ports are configured through the OPTIONS framework. You can fetch it from > http://black.daemons.gr/msid/knoby and modify it to suit your needs. Thanks > in advance. > > Sideris Michael. > _______________________________________________ > 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" -- Best Regards Yuan, Jue @ www.yuanjue.net