On 2/9/24 12:17 PM, Michael Orlitzky wrote:
> USE=unicode and USE=ipv6 are different beasts. In many cases they
> directly and immediately change the behavior of the package. I think
> that there are good reasons to want those two disabled, but the user's
> reasoning shouldn't really matter. The only "problem" in this case is
> the pkgcheck warning. Upstream supports it, the maintainer supports it,
> it works, users might want it, and it's one of our selling points.
> Given all of that, I'm leery of treating it like some kind of mistake.


Asking out of genuine ignorance: what kind of direct behavioral changes
occur as a result of setting or unsetting USE=ipv6.

I'm assuming that:

- users who don't want ipv6 are also masking it in the kernel at
  runtime

- users who do want ipv6 consider it a bug if the direct and immediate
  change is that the software is "broken because it fails due to lack of
  ipv6 support"

Along a similar line: I've never touched sbcl so again, I have *no* clue
what its deal is and am just curious: what are the advantages and
disadvantages of setting USE=unicode on it? In particular since it
defaults to on, under what circumstances would someone wish to unset it?

"There are good reasons" is pretty vague. I assume the reason is more
interesting than "when it is disabled, the package is buggy and broken
for certain use cases which the user has explicitly chosen to not care
about".

Does it make the package smaller?

Does it avoid depending on additional packages? (no...)

Are unicode strings sometimes bad to have, but users cannot choose the
string type except by recompiling the programming language itself? (Okay
if that is the case, but that seems a strange decision for a programming
language to make...)


-- 
Eli Schwartz