Robin H. Johnson wrote: [Thu Jul 07 2005, 05:07:06PM EDT]
> On Thu, Jul 07, 2005 at 04:49:13PM -0400, Aron Griffis wrote:
> > Current (possibly unwritten) policy:
> >   - eclasses declare USE-flags they honor in their own IUSE
> >   - ebuilds declare USE-flags they honor in their own IUSE
> >   - ebuilds do not declare USE-flags honored by eclasses they inherit
> 
> The policy itself is almost fine, it's the checking we need to improve.
> 
> The only policy problem case that is where an eclass has a flag
> declared, but the ebuild doesn't use that part of the eclass at all, on
> purpose.  Either the ebuild/eclass should be changed, or we should have
> a way to take flags out of IUSE further down the line.

I don't think the last suggestion makes sense.  It adds complexity to
IUSE declarations while increasing the linkage between eclasses and
ebuilds.  It's not much better to remove IUSE flags when they aren't
used than to add them when they are used...

> > So right now the policy is broken, but the apparent alternative is
> > unmanageable.  Ideas?
>
> Before changing more, it would be good to have some proper repoman
> checks for this stuff.

Before changing more what?

> It should be easily doable, as there are only a few proper ways to use
> USE flags in your ebuild. This would also help catch ebuilds/eclasses
> not declaring IUSE properly, or having old stuff in IUSE that isn't
> actually used anymore.
> 
> The only official ways to use USE flags are (at least to my knowledge):
> use FLAG
> usev FLAG
> useq FLAG
> use_enable FLAG
> use_with FLAG

The more complex eclasses have front-ends to USE, for example php and
mozconfig.  I think you will quickly find that it is not that "easily
doable" to catch this stuff in repoman, though it could certainly be
improved.

If you're going to teach repoman to read ebuilds and eclasses, create
a call graph, trace it for USE-flags, and generate what repoman thinks
IUSE should be...  well, suffice it to say I don't see this happening
soon.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer

Attachment: pgpzFXhRg1K1o.pgp
Description: PGP signature

Reply via email to