ports structure and improvement suggestions

[Shaun Amott]

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.

> 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.

> 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.

-- 
Shaun Amott [ PGP: 0x6B387A9A ]
    Scientia Est Potentia.