ports structure and improvement suggestions

[Sideris Michael]

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.