On Thu, 2021-07-08 at 13:17 -0700, Matt Turner wrote: > > 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've spent a great deal of time in the past moving flags from the base profiles into package defaults. Not that I see what that has to do with anything. I'm not arguing that you should do things the way I want except insofar as I'd prefer you to choose the way of doing things that has all of the benefits for you and none of the downsides for the rest of us. > > > > 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! No, this is a great case for the package default. Save some people a headache, and include the batteries for kmod. I'll disable that one manually if I know what I'm doing. But, the kmod situation is not a good reason to enable lzma support in FFmpeg. Given the above, it is maybe not surprising that sys-apps/kmod already has IUSE="+lzma +zlib". > > > 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. You don't find it compelling that changing the default globally has no additional benefits but a bunch of negative side effects? I *am* making that argument about all of the other tools. The bzip2/lzma/zstd support is mostly junk and should not be enabled by default, especially not globally. (If individual maintainers want to enable junk features by default, there's not much I can do except point out how unusually difficult it is to override.) > 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. You're the one trying to do something here but you haven't really said what yet. No, I don't want to spend hours reverse engineering what you're trying to accomplish when you could just tell us. Which packages do you think need these flags on by default, and why? If their maintainers agree, you don't need anyone else's approval.
