Re: [gentoo-dev] We have "doc" USE flag, why not a "man" USE flag too

[Jason Stubbs]

On Thursday 11 August 2005 21:26, Mike Frysinger wrote:
> On Thursday 11 August 2005 07:02 am, Jason Stubbs wrote:
> > On Thursday 11 August 2005 09:04, Mike Frysinger wrote:
> > > On Wednesday 10 August 2005 07:56 pm, Jason Stubbs wrote:
> > > > I was referring to compiler version. Portage FEATURES are not a
> > > > guaranteed part of an ebuild's "shell". Let me put it another way,
> > > > should ebuilds handle NOCOLOR as well?
> > >
> > > no, but why should NOCOLOR affect how a package is built/installed ?
> > > the point here is that we dont really care whether it's FEATURES or
> > > USE or what, as long as we have the ability to control
> > > DEPEND/SRC_URI/behavior in an ebuild depending on whether the user
> > > wants tests/manpages/etc...
> >
> > With noman and the like, how's the following for a solution? A lot of
> > the ebuild functions contained within portage will be moving into the
> > tree once signing is in. What about adding
> > {pre,post}_src_{compile,install,...} hooks into portage that will live
> > in the tree that USE="man" support can be implemented in globally? For
> > those packages that have a specific interest, the USE flag will be
> > available. Everything should be happy on the ebuild side of things. (On
> > the U/I side of things, stuff can be done to cut down the noise.)
>
> so you're saying that the default ebuild.sh functions are going to be
> moving into the tree to a place which will be auto-sourced before the
> ebuild and its eclasses ?

As Marius said, the list of what be moved isn't finalized yet. Essentially, 
the goal is to move anything that is not affected by portage version into 
the tree. What I was suggesting was extra hooks that would essentially 
allow ebuild devs to modify ebuilds at the abstract level, such as adding a 
"noman", "noinfo" or "nostaticlibs" to all ebuilds.

This is merely a suggestion, however. Putting aside my general dislike of 
USE_EXPAND, adding FEATURES to it means that all portage versions (and 
replacements) are required to have a global FEATURES setting and must have 
a certain subset of FEATURES available that must each provide a specific 
function. I'm not really attached to the solution I suggested; I'm just 
looking for a way to get rid of those "must"s. Portage currently has no 
idea what anything in USE or USE_EXPAND is or what it does. It needs to be 
kept that way.

-- 
Jason Stubbs