From owner-freebsd-ports@FreeBSD.ORG Mon May 8 20:09:40 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 B610B16A400 for ; Mon, 8 May 2006 20:09:40 +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 17DB343D5D for ; Mon, 8 May 2006 20:09:36 +0000 (GMT) (envelope-from msid@daemons.gr) Received: from [88.218.36.6] (port=62879 helo=localhost) by jefferson.hostingzoom.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FdC2t-0007SQ-DU for freebsd-ports@freebsd.org; Mon, 08 May 2006 15:09:35 -0500 Date: Mon, 8 May 2006 23:09:26 +0300 From: Sideris Michael To: freebsd-ports@freebsd.org Message-ID: <20060508200926.GA6005@daemons.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Subject: 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 20:09:41 -0000 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.