Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Apr 2011 05:01:44 +0000
From:      Baptiste Daroussin <baptiste.daroussin@gmail.com>
To:        Eitan Adler <eadler@freebsd.org>
Cc:        FreeBSD Ports <ports@freebsd.org>
Subject:   Re: Removing Cruft from the ports tree
Message-ID:  <AANLkTin%2BGOmg54Y8F7qrMErpqHnxEfGgiaB5b1s8NWEg@mail.gmail.com>
In-Reply-To: <AANLkTikmyPyY8q1xN47_dH3D6ndFoXYDaM3F%2BtWdFKe0@mail.gmail.com>
References:  <AANLkTikmyPyY8q1xN47_dH3D6ndFoXYDaM3F%2BtWdFKe0@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
2011/4/1 Eitan Adler <eadler@freebsd.org>:
> Hi,
>
> =A0 =A0I=92m been working recently on a series of PRs that called =93Reap=
er
> of the Dead=94 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.
>
> =A0 =A0One 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.
>
> =A0 =A0However 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.
>
> =A0 =A0Automated 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.
>
> =A0 =A0I 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.
>
> =A0 =A0While 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.
>
> =A0 =A0Feel 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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@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=3Dports/152568 for example
but it needs time to be reviewed by portmgr.

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.

My 2c,
Bapt



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin%2BGOmg54Y8F7qrMErpqHnxEfGgiaB5b1s8NWEg>