On Thu, 2021-07-08 at 11:15 -0700, Matt Turner wrote: > > So, the thing about running a minimal system is... you already have > these dependencies installed. This doesn't change that... > > I could of course change the default of every bzip2/lzma/zstd in IUSE > (and might as well handle zlib too so we can remove it from > make.defaults!) but what practical advantage does that bring?
There's more to being a dependency than just being installed. Not all of these packages have e.g. USE=zstd so that they can run /usr/bin/zstd. Some link against libzstd, which now bloats them to use a tiny bit more space and memory, as well as exposing you to any security problems in the library. Your dependency tree gets a little bit more complicated, and your package manager has to figure out how to do subslot rebuilds for everything when libzstd gets upgraded. Per-package defaults are easier to override, since I don't have to undo everything before setting the USE-flags that I wanted to enable in the first place. Per-package defaults are easier to revert if we change our collective minds later, since we don't have to test the entire tree for breakage first. Global flags have essentially undefined behaviour, since e.g. USE=bzip2 does different things for each package. As an extreme example, global flags affect packages that aren't even in the tree yet and that may use USE=bzip2 in a way you don't expect. As a less extreme example, USE=bzip2 may open your crypto library up to compression attacks. It definitely makes your dev-lang/php more vulnerable. (The same goes for USE=zlib, which should be removed in favor of per-package defaults.) Global flag settings increase complexity because they all interact with each other, creating a combinatorial explosion of interaction points. Figuring out how to turn a global flag off for a subset of packages can be a nightmare. Do you change the file where it's enabled? Or the arch profile where the enabling is reverted? Or the arch/desktop profile where the disabling is disabled? Or the hardened profile where the disabled disabling is disabled? Any argument against global variables in a program is an argument against global profile changes. > I doubt there's a sensible reason to build without any of these USE > flags enabled. I think the claim that most people will want them > enabled is not really a question. So we should enable them by default. > I think that logic is pretty straightforward. If someone wants to > disable the flags for some reason, they of course still have that > option. > > If you can find a case where you wouldn't want to enable one of these > USE flags, please let me know and I'll reconsider my position. > I don't have them enabled for any packages where they're not IUSE- defaulted, and haven't noticed any problems. Not not having a reason to do something isn't a good justification to do it. If it ain't broke and all that. If anyone wants them set, it's as easy as USE="lzma bzip2 zstd", and we are apparently all okay without them. If you have a good reason to do it for certain packages, setting per- package defaults is the way to do it. The base profile defaults are only there because we didn't always have per-package defaults. But, if you really look, I think you'll find that most of these flags do completely useless things. Do you REALLY need libpcre to build and install you a special executable called "pcregrep-libbz2" that just pipes bunzip2 to pcregrep? No, nobody does. And most other uses are comparably stupid.
