1 |
On Thu, 2021-07-08 at 13:17 -0700, Matt Turner wrote: |
2 |
> |
3 |
> I hear you, and I appreciate the theoretical concerns. |
4 |
> |
5 |
> I could maybe even support this position if you were actively working |
6 |
> towards this new and glorious future, but the only time I hear |
7 |
> anything about it is when you're arguing that someone else should do |
8 |
> something the way you want. |
9 |
|
10 |
I've spent a great deal of time in the past moving flags from the base |
11 |
profiles into package defaults. Not that I see what that has to do with |
12 |
anything. I'm not arguing that you should do things the way I want |
13 |
except insofar as I'd prefer you to choose the way of doing things that |
14 |
has all of the benefits for you and none of the downsides for the rest |
15 |
of us. |
16 |
|
17 |
|
18 |
> > |
19 |
> > I don't have them enabled for any packages where they're not IUSE- |
20 |
> > defaulted, and haven't noticed any problems. Not not having a reason to |
21 |
> > do something isn't a good justification to do it. If it ain't broke and |
22 |
> > all that. If anyone wants them set, it's as easy as USE="lzma bzip2 |
23 |
> > zstd", and we are apparently all okay without them. |
24 |
> |
25 |
> Well, you're okay without them until you need them: E.g., enable |
26 |
> CONFIG_MODULE_COMPRESS / MODULE_COMPRESS_XZ without knowing that you |
27 |
> need sys-apps/kmod[lzma] and your system becomes unbootable. |
28 |
> |
29 |
> But you're of course right that some die-hards might rather accept |
30 |
> this risk and save the 8 KiB of disk space (424 KiB → 436 KiB) they'd |
31 |
> lose out on by enabling USE=lzma for the package. But the good news |
32 |
> is.. they still can! |
33 |
|
34 |
No, this is a great case for the package default. Save some people a |
35 |
headache, and include the batteries for kmod. I'll disable that one |
36 |
manually if I know what I'm doing. But, the kmod situation is not a |
37 |
good reason to enable lzma support in FFmpeg. |
38 |
|
39 |
Given the above, it is maybe not surprising that sys-apps/kmod already |
40 |
has IUSE="+lzma +zlib". |
41 |
|
42 |
|
43 |
> |
44 |
> > But, if you really look, I think you'll find that most of these flags |
45 |
> > do completely useless things. Do you REALLY need libpcre to build and |
46 |
> > install you a special executable called "pcregrep-libbz2" that just |
47 |
> > pipes bunzip2 to pcregrep? No, nobody does. And most other uses are |
48 |
> > comparably stupid. |
49 |
> |
50 |
> I mean, you could make that argument for bzless or any other version |
51 |
> of these tools. I don't find that compelling. |
52 |
|
53 |
You don't find it compelling that changing the default globally has no |
54 |
additional benefits but a bunch of negative side effects? I *am* making |
55 |
that argument about all of the other tools. The bzip2/lzma/zstd support |
56 |
is mostly junk and should not be enabled by default, especially not |
57 |
globally. (If individual maintainers want to enable junk features by |
58 |
default, there's not much I can do except point out how unusually |
59 |
difficult it is to override.) |
60 |
|
61 |
|
62 |
|
63 |
|
64 |
> Maybe you'd like to audit the compression USE flags and make |
65 |
> recommendations for which you think do completely useless things? I |
66 |
> can pretty easily replace this patch with a set of |
67 |
> automatically-generated patches that enable these USE flags by default |
68 |
> for all packages but on a per-package basis. |
69 |
|
70 |
You're the one trying to do something here but you haven't really said |
71 |
what yet. No, I don't want to spend hours reverse engineering what |
72 |
you're trying to accomplish when you could just tell us. Which packages |
73 |
do you think need these flags on by default, and why? If their |
74 |
maintainers agree, you don't need anyone else's approval. |