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
pgpcgWZqevb4L.pgp
Description: PGP signature
