Removing Cruft from the ports tree

[b. f.]

> Hi,
>
>     I’m been working recently on a series of PRs that called “Reaper

I'm glad to see that you're helping to clean up.

>
>     One of the features that has given us the most trouble has been
> the options framework for ports. We automatically test ports using the
> default options, but we are unable to perform automated using every
> combination of options. A port with just four options has sixteen
> possible configurations, and some ports have more than that. Even
> supporting one option might double the number of things to test.
>
>     However some ports rely on specific configurations of options of
> other ports. In order to deal with this mess we have come up with a
> hack: slave ports. We have entire ports that are designed just to
> change the default options for other ports. This requires a
> non-trivial amount of code on the bsd.*.mk files to support.
>
>     Automated configuration is not the only thing that has caused us
> trouble in the past. We routinely have to do deal with questions from
> inexperienced users on questions@ and ports@ details problems with
> non-standard configurations. Many times the solution to a ports
> related problem is flipping a bit in the options file.
>
>     I propose removing the options systems entirely. While it does
> serve a small purpose of allowing customization for some end users, I
> believe the flaws outweigh the benefits. Removing the options
> framework would enable us to remove over 500 lines of expensive code
> from the ports system. Not only that but because maintainers would be
> able to choose the best possible configuration for the their port
> users would no longer have to mess around.
>
>     While I understand there might some minor part of the community
> that has a sentimental attachment to the blue-on-gray-on-blue
> configuration, and still others want to prematurely optimize, a simple
> workaround could be implemented. We can allow users to add their own
> ./configure arguments to the makefile. This serves the needs of the
> community while allowing us to deal with a simpler and more reliable
> ports system.

The ports system does not exist just to build packages with fixed
configurations.  The ability to configure ports offers an important
degree of flexibility, and one that is not always "sentimental",
"minor", or "premature".  One size doesn't fit all. Your point that
"many times the solution to a ports related problem is flipping a bit
in the options file" cuts both ways.  Flexibility requires more than
just allowing user-specified arguments to a configure script.   Yes,
it adds some effort to maintenance and testing, and some judgement and
discussion is needed when deciding what options to expose.  (And no,
the port maintainer is not always the best judge, or at least not the
only judge, of port configuration.) Occasionally users may be confused
by choices,  but they are just as likely to complain about a lack of
choices.  Fixed configurations will probably lead to pressure for more
slave ports in the form of ports with alternative fixed
configurations,  and not fewer.  If you remove all flexibility from
Ports, then many users will abandon Ports for something else, or be
forced to maintain locally modified Ports trees that often won't be
available for others to use, examine, and test. I think that we should
encourage those users who would be best served by binary packages to
use them, make an attempt to address the questions and problems of
those that need non-default options, work on improving the OPTIONS
framework, and provide a better way of dealing with alternative
dependencies, like those in some other packaging systems.  But I
strongly oppose removing options altogether.


>
>     Feel free to express your thoughts here. I would like to get this
> hashed out now so the process could occur on a later date(1).
>

What process?  I hope that you are asking for our opinions, and not
just assuming that you going to carry out this proposal.

b.