Removing Cruft from the ports tree

[Mehmet Erol Sanliturk]

On Thu, Mar 31, 2011 at 11:55 PM, Eitan Adler <eadler at freebsd.org> wrote:

> Hi,
>
>    I’m been working recently on a series of PRs that called “Reaper
> of the Dead” PRs. I have been going through the various build files we
> have (for source, docs, and especially ports) and attempting to remove
> dead code, old cruft, and unneeded checks. Some examples include
> ports/155543, ports/155511, ports/154395, conf/155737, and
> conf/155738. My goal has been twofold: making it easier to understand
> what is going on, and speeding up the process without requiring
> significant change.
>
>    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.
>
>


The idea specified above is really very good , because , during  ¨make
install ...¨
installations , given a ( non-tested previously ) improper selection
sometimes wasting important number of hours because at some point make is
producing an error .

Sometimes , all of the options may work in the computer of the maintainer or
tester because some required parts may already be present in their systems .
When a user tries to install such a port into a new computer may lead to
failure because those different parts are not present in the new computer .
Many times I am encountering that problem , and I wish that the maintainer
should test that in a CLEAN computer to encounter the same problem before
releasing the subject software .

Actually , sometimes the options are really not necessary to ask because to
use ( the port under work ) may use it , therefore why to ask about such an
option : Instead of asking at least YES or NO , assume worst case as YES ,
and take actions with respect to this answer , or select the best default
and leave the other parts to be completed by the installer with respect to
his/her needs .

When such an approach is used , ONLY a SINGLE case will be tested with
outcome as Success or Failure
which correction of problem in that case will be very easy by either
removing the optional part or making ready it .

As said above , number of possible test cases is an exponential requirement
such as
 ( Number of options to test ) to 2 ( at least when there are only YES or NO
selections )
which requires exponential work to test the possibilities .

This is an enormous work requirement . It is obvious that the port
maintainers working hard to serve to the community . Instead of increasing
their work complexity from linear to exponential ( which is really an
unnecessary burden to them ) always we try to eliminate their burdens as
much as possible .


-------------------------------------------------------------------


>    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.
>
>    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).
>
> --
> Eitan Adler
>


Thank you very much .

Mehmet Erol Sanliturk