svn commit: r490910 - in head: Mk Mk/Uses mail/thunderbird www/firefox www/firefox-esr www/firefox-i18n www/firefox/files www/palemoon www/seamonkey

[Jan Beich]

Alexey Dokuchaev <danfe at freebsd.org> writes:

> On Wed, Jan 23, 2019 at 06:52:09AM +0100, Jan Beich wrote:
>
>> Alexey Dokuchaev <danfe at freebsd.org> writes:
>> > On Wed, Jan 23, 2019 at 10:17:42AM +0800, Martin Wilke wrote:
>> >> On Tue, Jan 22, 2019 at 09:52:11PM +0100, Christoph Moench-Tegeder wrote:
>> >> > ...
>> >> > Given that WAYLAND is the default for us, and "without wayland"
>> >> > might be untested anyways - would it make sense to remove the
>> >> > WAYLAND option and force it to "on" always?
>> >
>> > Please don't.  I have zero reasons to want/enable Wayland bits and deal
>> > with all the extra bloat that comes with it.  Modern FreeBSD/X.org stack
>> > is quite bloated already (e.g. compared with my 8.4-STABLE setup).
>> 
>> And I have zero reasons to fight your WAYLAND=off battle. If all you
>> can offer are bikesheds then like with PulseAudio expect me to not care.
>
> While both Wayland and PulseAudio are of course useless pieces of software,
> I did not object Wayland being enabled by default as long as I can turn it
> off.  I don't see how this level of granularity is bikeshed.  There are
> large parts of functionality that are completely useless for various groups
> of people (graphics support for servers, CUPS support for users without a
> printer, etc.) and thus were traditionally made optional.  Pulling Wayland
> unconditionally goes against the way we do things (and did for years) in
> FreeBSD Ports Collection.

If Firefox upstream drops support for building WAYLAND=off then I'm not
going to spend extra effort to keep it alive.