ports structure and improvement suggestions

[Sideris Michael]

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.