On Thu, Feb 2, 2017 at 12:01 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <m...@gentoo.org> wrote: > > > > If (base == minimal), then all of the upstream defaults need to be added > > to package.use for the upstream-defaults profile. That's bad, > > I'll go further and say that it is unacceptably bad. > > > but if > > (base == upstream-defaults), then the important IUSE defaults need to be > > copy/pasted from our ebuilds into the minimal profile. The latter is > > more spiritually damning =) > > > > So, I'll admit I've never been one that cared a great deal about > minimalism so I appreciate that I may not be the best one to judge > this, so let's go ahead and embrace your statement for the purpose of > debate. > > Is there a better way we can have our cake and eat it too? I'll admit > that a huge package.use on the minimal profile isn't a whole lot > better than a huge package.use on all the other profiles. > > Do we need another form of syntax in individual ebuilds to try to > separate out the various cases you cite? Does anybody care to > actually suggest one? > > I still think that we shouldn't encourage users to lightly deviate > from all the upstream defaults. There are of course legitimate > reasons for doing so, and you and I can probably appreciate when we > should do this, but for somebody starting out we're giving them a lot > of rope to hang themselves with. It is like building a kernel > answering no to the largest number of questions possible while still > actually building something. I'd actually be curious as to what that > kernel would even be capable of doing (there are a lot of fairly > essential things you can turn off in the kernel). > > In the same way, we shouldn't be too quick to deviate from upstream > defaults ourselves (#4 in your example), beyond actual integration > work. > > I'll admit the current state is a bit of a compromise, but I don't > think we should change it unless we're changing it to something > significantly better. This is a pretty big-impact change. > > -- > Rich > If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't allow any granularity. Another variable USE_PROFILE should be added analogue to DEPENDS: IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme annoyingUpstreamDefault" USE_PROFILE=" desktop? ( pulseaudio ) gtk? ( gtk-theme ) gnome? ( @gtk gnome-keyring) kde? ( @qt kwallet ) qt? ( qt-theme ) upstream? ( annoyingUpstreamDefault ) " @ is already used for sets, so "some other use_profile's set of defined flags" seems reasonable. It should be additive only, so no +- prefixes needed (or allowed). If a package is emerged without any USE_PROFILE set, you might einfo "This package supports was emerged with no use profile. It supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE should never have any default selected by an ebuild; if a flag is required to build, is shouldn't be a flag. You get independent behavior per package rather than listing every single package that ever existed in profile/package.use, package behavior actually being with the package instead of global profiles, and you get rid of the mess of uncustomizable IUSE="+something" everywhere that makes people like me tend to start off every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf. Just need to come up with sane naming convention for common possibilities like kde, gnome, and generic desktop. If you want upstream, USE_PROFILE="upstream". If Gentoo as an organization wants that to be the "friendly to new user" standard, put USE_PROFILE="upstream" in the stage3 make.conf, where those of us who want to can simply remove or change it instead of having to nuke everything with USE="-*". You can still use e.g. RUBY_TARGETS="+ruby21" in an ebuild if you want a default for things that really require an at-least-one-of choice. Then instead of default/linux/amd64/13.0/desktop/kde listing any USE flags itself, it just sets required USE_PROFILE and lets the packages do their thing.
