Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, On 02/01/2022 01.03, Scott Ellis wrote: Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to have IPv6 support built into things (just another potential "thing" that I have to secure, or errors/warnings I need to suppress since I run an IPv6-less kernel). If there needs to be a path to culling USE flags, perhaps looking to which flags actually cause packages to pull in additional dependencies (vs solely enable/disable a feature) would be a better place to start? And here I am having a deja vu, an associate of mine who happens to use Gentoo also intentionally runs without IPv6. When we were traveling out of country he was unable to use WIFI hotspot that I was connected to, turns out, it was IPv6-only hotspot with NAT64 gateway. I had internet access, he had rant about why IPv6-only networks are abomination and that he never seen a network like it. He won nothing, and neither do you win anything running without IPv6 support. -- Piotr.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On 2022.01.02 07:33, Sam James wrote: > [snip] > Note that having USE flags for things, even if forced on/masked (for > the opposite case) is useful for building embedded systems. So, if you > wanted to go this route, a sensible > first step would actually be forcing PAM on. But I don't think PAM is > a candidate for dropping. > > While I think it's hard to run a modern desktop system without it, > there are a fair number of people who do still run -pam and I don't > think > breaking it for the sake of it is a good idea. They already know there > be dragons. > > > > > Whats your view on it? > > I think I broadly agree, although PAM is a mildly controversial > example. > > I'd like to discuss specific examples of flags like USE=threads, > some-if-not-all instances of USE=ipv6, > And others which people raise if any others come up. > > Best, > sam > I'll stir the USE=-pam pot. A static busybox is a very good thing but that can only be achieved with USE=-pam. Sometimes it's the only way to pick up the pieces. In general, where USE=-foo makes the code size smaller I would be against dropping it. Think non Intel/AMD memory constrained systems. Gentoo is popular outside the desktop, so keep those users in mind too. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpCLMlWhJelZ.pgp Description: PGP signature
[gentoo-dev] Last rites: sys-auth/pam_blue
# Florian Schmaus
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On Sat, Jan 01, 2022 at 11:21:40PM +0100, Piotr Karbowski wrote: > As example I'd like to use 'ipv6' USE flag, at the moment of writing > this email there's 351 ebuilds in tree that expose ipv6 as USE flag, > allow it to be disabled. This is a flag I've usually been removing when I touch a package already, not that I'd want to spearhead removing it from /all/ packages at once but well. In most cases it's: - an upstream default - has no extra dependencies - doesn't increase file size in any noticeable way - ipv6 is expected to work - USE=-ipv6 tend to have less-tested code paths that I've seen cause issues even for ipv4 - not really anything to gain by disabling in a specific package even if you don't use ipv6, there's plenty of ways to disable ipv6 - majority of packages don't even have a switch to disable either way, this is mostly historical switches from early days of support I'd keep it if say the package needed libsuperipv6 or something as I'm not particularly an advocate that it /must/ be supported, and in this case libsuperipv6 may be less wanted or even not supported on some arches (maybe was written in rust!) > Beside 'ipv6', there are other USE flags that I have on mind. 'pam' > being another of them. That's one I think needs to be kept even if I don't like the idea of normal desktop system arbitrarily disabling it where about everything expects it to be used. Disabling can make sense on prefix, embedded systems and similar -- and it also need extra dependencies and cause more relevant changes in behavior that users should be free to want or not. Not that should be responsible for upstreams supporting disabling it, so when they don't just depend on it being enabled (what we do now). -- ionen signature.asc Description: PGP signature
