From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 306A4139085 for ; Fri, 3 Feb 2017 08:16:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 10F14E0D1F; Fri, 3 Feb 2017 08:16:18 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AF8D4E0D1A for ; Fri, 3 Feb 2017 08:16:17 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cZZ2M-0002Vb-Le for gentoo-dev@lists.gentoo.org; Fri, 03 Feb 2017 09:16:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Guidelines for IUSE defaults Date: Fri, 3 Feb 2017 08:16:01 +0000 (UTC) Message-ID: References: <08443117-9f0f-9858-fc8b-ce80b49fd22d@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.142 (He slipped to Sam a double gin; 6072d9a47) X-Archives-Salt: 01a53e89-5eb7-497b-be5e-b20b4d0ca048 X-Archives-Hash: a7e330ebe66c3330ac90a01848e02561 Michael Orlitzky posted on Thu, 02 Feb 2017 10:49:41 -0500 as excerpted: > On 02/02/2017 09:56 AM, Ian Stakenvicius wrote: >> >>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky >>> wrote: >>> >>> IUSE defaults are used in a few different ways: >>> >>> 1 To ensure that critical functionality is enabled. >>> >>> * Example: force the "unix" module for apache. >>> >>> >> This is not what IUSE defaults are for, this should be done with >> package.use{,.stable}.{mask,force} in profiles. If functionality is >> critical then there (A) shouldn't be a use flag, or (B) shouldn't be a >> way for USE= in make.conf to disable it. >> >> > If we adopted this policy, then USE="-*" would no longer be guaranteed > to break the system. It does still ignore your profile defaults, though, > which presumably are important (e.g. for hardened). So we're still left > with no way for me to turn off everyone's pet USE flags and keep my > system working. If USE="-*" is a guarantee of a broken system, it's a pretty weak one. In fact, so is flying with an empty @system (everything in the profile negated), as I do both of the above. And in fact, my gentoo-based-admin life has been far simpler since I set it up that way. =:^) The biggest benefit of USE="-*" is that I no longer have to worry about investigating the "why" of USE flag changes when I change to a different profile, or when devs change my existing profile out from under me. I have a set of USE flags I've decided I want (or need for long-term- installed stuff like kde), and all packages that don't work with that default -- for instance, packages that required-use qt4 XOR qt5, already have their package.use setup as appropriate. Otherwise, when I upgrade to a new profile, as I've needed to do several times over the nearing a decade and a half I've been running the same original installation rolling-update gentoo on rolling-update hardware, I have to do a bunch of research on all the USE flags that changed and how they affect my existing installation due to --newuse. This way, that was all managed at the time I encountered the original USE flag conflict, and the profile I choose doesn't mess with my USE flags at all except via forces (which I can override if I have to, but I haven't had to, a testament to the wisely conservative usage of forced-USE). Of course, I can and do still use the USE flags set in a profile as a guide, and that was a tremendous help in the kde-apps5/frameworks5/plasma5 upgrade process despite the fact that I couldn't actually use the profile designed for that. The biggest weakness, meanwhile, is that with USE="-*" there's no easy way to actually see what a package's USE-defaults are, without actually opening up the ebuild (or at least grepping) to see. I've often wished there was some way to denote the default-on flags in emerge --pretend/-- ask so I could see what they are on a new package, and investigate why if necessary, but I understand the problem of a limited available symbol- space, and actually looking in the ebuild isn't /horribly/ hard... as long as there's multiple terminals available to do it in, without unnecessarily canceling the --ask output that took so long to appear. Of course it would be a bit different if I could actually use a profile with all the bits I needed, nomultilib, systemd, plasma, amd64, primarily. But until mixins, nomultilib generally means at least some of the other stuff isn't available in a profile, so I gotta simply pick the nomultilib profile that best matches and check the other profiles, for example plasma, using them as a guide to set my flags the way I need them. Similarly with @system. Negating the entire thing a package at a time and seeing what --depclean wants to clean, then adding as appropriate to a set listed in world_sets if it's /really/ needed, means I don't have to worry about package.providing openrc, for instance, because it's not necessary with systemd, once a single symlink is setup. Similarly with ssh if it's only a stand-alone system you're admining. And most of the @system virtuals can simply be dropped, as specific selections from those virtuals have already been added to some set listed in world_sets. Of course it helps that my routine-use emerge aliases have --ask --verbose --oneshot. (I don't configure those as emerge-defaults because I do for example want --pretend occasionally instead of --ask.) But that's a lesson most gentooers should have learned within six months. Anyway, USE="-*" hardly breaks the system here. In fact, rather the opposite, it fixes what was previously a major headache of a workaround for a broken system every time my profile changed, because I was setting most USE flags I wanted but until then, not *ALL* of them, in part because I couldn't see what I had missed because the profile was setting it for me... until it didn't, thus creating the problem. So for some people, especially those likely to have systems they're managing over a profile upgrade, USE="-*" is a guaranteed fix, not a guaranteed break. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman