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
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
