Removing Cruft from the ports tree

[David DEMELIER]

2011/4/1 Baptiste Daroussin <baptiste.daroussin at gmail.com>:
> 2011/4/1 Eitan Adler <eadler at freebsd.org>:
>> 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.
>>
>>    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
>> _______________________________________________
>> 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"
>>
>
> Removing the option framework is an option if it is replaced, by
> something equivalent, I have proposed
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/152568 for example
> but it needs time to be reviewed by portmgr.
>

The best work done ever to the ports tree.

> This new implementation of option is more consistent and cleaner.
>
> The slave ports is not a solution only to make sure we have a port
> with a given option set, but it is also a way to avoir code
> duplication (php for exemple).
>
> pkgng can register this options passed to a port to an installed
> package, along with my option framework proposal, it would allow us to
> be able to check the configuration of a given port from the port
> infrastructure.
>

And it just rocks! :-)

> My 2c,
> Bapt
> _______________________________________________
> 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"
>



-- 
Demelier David