On Thu, Jul 8, 2021 at 12:36 PM Michael Orlitzky <m...@gentoo.org> wrote: > > 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 hear you, and I appreciate the theoretical concerns. I could maybe even support this position if you were actively working towards this new and glorious future, but the only time I hear anything about it is when you're arguing that someone else should do something the way you want. > > 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. Well, you're okay without them until you need them: E.g., enable CONFIG_MODULE_COMPRESS / MODULE_COMPRESS_XZ without knowing that you need sys-apps/kmod[lzma] and your system becomes unbootable. But you're of course right that some die-hards might rather accept this risk and save the 8 KiB of disk space (424 KiB → 436 KiB) they'd lose out on by enabling USE=lzma for the package. But the good news is.. they still can! > 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. Yes, things are the way they are because of history. > 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. I mean, you could make that argument for bzless or any other version of these tools. I don't find that compelling. But also, I have USE=bzip2 on libpcre and I don't have pcregrep-libbz2. Regardless, I'm not going to lose any sleep over it if it appears with the next upgrade. Maybe you'd like to audit the compression USE flags and make recommendations for which you think do completely useless things? I can pretty easily replace this patch with a set of automatically-generated patches that enable these USE flags by default for all packages but on a per-package basis. FWIW, I generally agree that there are a lot of USE flags that should not exist -- we should reduce the complexity of configuring the system by removing USE flags that don't have a downside. I'd claim most of these packages' bzip2/lzma/zstd USE flags should be removed in favor of statically enabling them, but that probably would garner a stronger response than this patch.
