Re: text-to-speech in firefox (Re: firefox-116)

[Greg Troxel <gdt%lexort.com@localhost>]

pin <voidpin%protonmail.com@localhost> writes:

>> Also, options don't play well with binary packages. The default
>> controls what binary packages do, and there the build cost is less of a
>> concern. 
>
> I no longer use binary packages, I've running HEAD for over two years and there are no binaries.
> Another reason for building everything locally, is that there are other packages where the defaults don't suite my taste.

Sure, but having options and especially their defaults have to be
considered in the context of binary packages, because "official
binaries" are by definition are built with all defaults.  You doing what
you want privately is one thing, but you are asking to have pkgsrc
changed, and that has to be considered globally, not in the context of
how you use it.

(I build my own packages too, including a build system that creates
binaries that I use on other systems.)

>> Without knowing what's going on, TTS seems like a useful feature,
>> especially for those with vision impairment, and if firefox in general
>> has this, it seems that the default pkgsrc build should too. So if it
>> were an option, it would be on.
>
> Agreed. It can be very useful for many people and it should be default ON.

ok - I misread.

>> It's a little hard to tell what the total change in dependency footprint
>> is, but a quick look makes me think it's fairly minor, especially if one
>> considers build tools.
>
> It's about choice, not the amount of dependencies or, it's footprint.
> I have more than enough disk space.

Adding an option has costs in terms of maintenance and cognitive load.
It means the maintainer has to check that PLIST is correct after each
update with and without the option.  It gives anyone building the
package more to understand.  Generally I think the fewer options the
better, and the best path is to make changes to reduce the need.
E.g. cups used to drag in replacement lpr, which was bad, and now is
split into libcups and cups-base, so things that want to print with cups
can just use libcups, which is non-offensive (even though some are
offended :).

Sometimes the balance of benefits to users from the option is higher
than the costs, and sometimes it isn't.

In this case, it might or might not be sensible -- but you did not give
rationale about the balance, just that you were offended by these
libraries being dependencies.

You saying simply that you want to choose is entirely unconvincing.  a
vast number of people could each want to remove any particular library
from any particular package, and optionizing all of them would be a
completely unreasonable outcome.

You certainly have a right to choose, and you can modify your copy of
pkgsrc.  But what you are asking is not to have the right to choose, but
to have all the rest of the pkgsrc community bear the cost of having the
option.

>> Overall my impression is that the basic issue is that firefox is not for
>> you :)
>
> That's also correct :)
> Unfortunately, there is no choice. I've tried for a year or so and came back to it.
> We don't have chromium and even if we did, I wouldn't use it.
> Firefox is the best of two evils.

Understood, and many others have the same sorts of feelings.

>> It's large and fairly bloated, requires large and memory-piggy
>> tools to build
>
> If you mean Rust, that doesn't bother me. Rust is one of the first things I build on a new set-up anyway.

Objecting to a few audio libs and being happy with rust does not make
sense to me.  That's ok -- there is no need for us to understand each
other's preferences!

But seriously, bloated programs pull in a lot, and as long as the bloat
is not that much worse, and what is pulled in is not actually
objectionable (proprietary, bad behavior e.g. tracking, unsafe), then I
don't think it's reasonable to want facilities to tweak it all.  pkgsrc
as a general rule tends not to tilt against upstream windmills except
when it's necesssary.

An ideal world would of course be very different, but if upstreams
provided plugins that were built separately, then we'd just have
packages for plugins.  The "options are trouble" is not just pkgsrc - it
also applies to other packaging systems.