ports structure and improvement suggestions

Tue May 9 16:37:47 UTC 2006

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"

-- 
Best Regards
Yuan, Jue @ www.yuanjue.net