1 |
On Thu, Jul 8, 2021 at 12:36 PM Michael Orlitzky <mjo@g.o> wrote: |
2 |
> |
3 |
> On Thu, 2021-07-08 at 11:15 -0700, Matt Turner wrote: |
4 |
> > |
5 |
> > So, the thing about running a minimal system is... you already have |
6 |
> > these dependencies installed. This doesn't change that... |
7 |
> > |
8 |
> > I could of course change the default of every bzip2/lzma/zstd in IUSE |
9 |
> > (and might as well handle zlib too so we can remove it from |
10 |
> > make.defaults!) but what practical advantage does that bring? |
11 |
> |
12 |
> There's more to being a dependency than just being installed. Not all |
13 |
> of these packages have e.g. USE=zstd so that they can run |
14 |
> /usr/bin/zstd. Some link against libzstd, which now bloats them to use |
15 |
> a tiny bit more space and memory, as well as exposing you to any |
16 |
> security problems in the library. Your dependency tree gets a little |
17 |
> bit more complicated, and your package manager has to figure out how to |
18 |
> do subslot rebuilds for everything when libzstd gets upgraded. |
19 |
> |
20 |
> Per-package defaults are easier to override, since I don't have to undo |
21 |
> everything before setting the USE-flags that I wanted to enable in the |
22 |
> first place. |
23 |
> |
24 |
> Per-package defaults are easier to revert if we change our collective |
25 |
> minds later, since we don't have to test the entire tree for breakage |
26 |
> first. |
27 |
> |
28 |
> Global flags have essentially undefined behaviour, since e.g. USE=bzip2 |
29 |
> does different things for each package. As an extreme example, global |
30 |
> flags affect packages that aren't even in the tree yet and that may use |
31 |
> USE=bzip2 in a way you don't expect. As a less extreme example, |
32 |
> USE=bzip2 may open your crypto library up to compression attacks. It |
33 |
> definitely makes your dev-lang/php more vulnerable. (The same goes for |
34 |
> USE=zlib, which should be removed in favor of per-package defaults.) |
35 |
> |
36 |
> Global flag settings increase complexity because they all interact with |
37 |
> each other, creating a combinatorial explosion of interaction points. |
38 |
> Figuring out how to turn a global flag off for a subset of packages can |
39 |
> be a nightmare. Do you change the file where it's enabled? Or the arch |
40 |
> profile where the enabling is reverted? Or the arch/desktop profile |
41 |
> where the disabling is disabled? Or the hardened profile where the |
42 |
> disabled disabling is disabled? Any argument against global variables |
43 |
> in a program is an argument against global profile changes. |
44 |
|
45 |
I hear you, and I appreciate the theoretical concerns. |
46 |
|
47 |
I could maybe even support this position if you were actively working |
48 |
towards this new and glorious future, but the only time I hear |
49 |
anything about it is when you're arguing that someone else should do |
50 |
something the way you want. |
51 |
|
52 |
> > I doubt there's a sensible reason to build without any of these USE |
53 |
> > flags enabled. I think the claim that most people will want them |
54 |
> > enabled is not really a question. So we should enable them by default. |
55 |
> > I think that logic is pretty straightforward. If someone wants to |
56 |
> > disable the flags for some reason, they of course still have that |
57 |
> > option. |
58 |
> > |
59 |
> > If you can find a case where you wouldn't want to enable one of these |
60 |
> > USE flags, please let me know and I'll reconsider my position. |
61 |
> > |
62 |
> |
63 |
> I don't have them enabled for any packages where they're not IUSE- |
64 |
> defaulted, and haven't noticed any problems. Not not having a reason to |
65 |
> do something isn't a good justification to do it. If it ain't broke and |
66 |
> all that. If anyone wants them set, it's as easy as USE="lzma bzip2 |
67 |
> zstd", and we are apparently all okay without them. |
68 |
|
69 |
Well, you're okay without them until you need them: E.g., enable |
70 |
CONFIG_MODULE_COMPRESS / MODULE_COMPRESS_XZ without knowing that you |
71 |
need sys-apps/kmod[lzma] and your system becomes unbootable. |
72 |
|
73 |
But you're of course right that some die-hards might rather accept |
74 |
this risk and save the 8 KiB of disk space (424 KiB → 436 KiB) they'd |
75 |
lose out on by enabling USE=lzma for the package. But the good news |
76 |
is.. they still can! |
77 |
|
78 |
> If you have a good reason to do it for certain packages, setting per- |
79 |
> package defaults is the way to do it. The base profile defaults are |
80 |
> only there because we didn't always have per-package defaults. |
81 |
|
82 |
Yes, things are the way they are because of history. |
83 |
|
84 |
> But, if you really look, I think you'll find that most of these flags |
85 |
> do completely useless things. Do you REALLY need libpcre to build and |
86 |
> install you a special executable called "pcregrep-libbz2" that just |
87 |
> pipes bunzip2 to pcregrep? No, nobody does. And most other uses are |
88 |
> comparably stupid. |
89 |
|
90 |
I mean, you could make that argument for bzless or any other version |
91 |
of these tools. I don't find that compelling. |
92 |
|
93 |
But also, I have USE=bzip2 on libpcre and I don't have |
94 |
pcregrep-libbz2. Regardless, I'm not going to lose any sleep over it |
95 |
if it appears with the next upgrade. |
96 |
|
97 |
Maybe you'd like to audit the compression USE flags and make |
98 |
recommendations for which you think do completely useless things? I |
99 |
can pretty easily replace this patch with a set of |
100 |
automatically-generated patches that enable these USE flags by default |
101 |
for all packages but on a per-package basis. |
102 |
|
103 |
FWIW, I generally agree that there are a lot of USE flags that should |
104 |
not exist -- we should reduce the complexity of configuring the system |
105 |
by removing USE flags that don't have a downside. I'd claim most of |
106 |
these packages' bzip2/lzma/zstd USE flags should be removed in favor |
107 |
of statically enabling them, but that probably would garner a stronger |
108 |
response than this patch. |