Removing Cruft from the ports tree

Zhihao Yuan lichray at
Fri Apr 1 05:35:11 UTC 2011

On Thu, Mar 31, 2011 at 11:29 PM, Mehmet Erol Sanliturk
<m.e.sanliturk at> wrote:
> On Thu, Mar 31, 2011 at 11:55 PM, Eitan Adler <eadler at> 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 .

Whenever I adds an option to a port, I tests all of the combinations,
with the related dependencies missing or met. Then I ask committers to
test them in tinderbox. I think maintainer should take responsible for
that, not the options system.

Options do make sense. In some cases, one single options can
eliminate/add over 50 dependencies, which save/waste all users' time.
We maintainers/developers exists to save users' time.

Not just the time to build ports! In a world without options, like
Archlinux, just check its AUR repository -- one software may have 10
pages of different PKBGUILDs! Options significantly limit the
increasing of the different package names.

A good example of to make use of options is Gentoo's ebuild system.
The USE_* flags are nothing new, but they are standardized. We may
need to standardize our WITH_*/WITHOUT_* flags instead of giving a
"commonly use flags" instruction.

> -------------------------------------------------------------------
>>    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
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

Zhihao Yuan
The best way to predict the future is to invent it.

More information about the freebsd-ports mailing list