On Sun, 23 Jan 2005 22:21:43 -0500
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > dev-java/jdictrayapi:examples - Install example source code
>
> is there a reason this isnt the same as USE=doc ?
Would it be bloat to add some finer grained "doc-*" global USE
flags? I'm thinking of something like that:
- doc-user: Install user manuals, help files, etc.
- doc-devel: Install developper doc, like API reference
- doc-examples: Install code or configuration examples
- doc-printable: Build printable (ps, pdf, etc.) documentation
Actually, my feeling is that the "doc" flag currently has to many
different meanings for beeing a good global flag (assuming that
a "good global flag" is such that for most users, it makes sense
to set it, or not, in make.conf, with only rare exceptions for
package.use).
For instance, in general i don't care about API references manual
(but for the few languages and libs I program with, which are less
than ten packages), whereas I always want all user manuals that
are available. Thus i came to the conclusion that i should not
set "doc" globally, and that when an ebuild has IUSE=doc, i should
read it to know what it is about and decide whether i add an entry
to my package.use. That's a bit boring, and introducing a
-user/-devel distinction would solve that.
Also, i often see packages that uses the "tetex" flag in addition
to "doc" to build postscript version of their documentation. That
doesn't match this flag description ("Adds support for teTeX")
when that's packages that are not related to TeX stuffs at all.
But on the other hand, since building such docs adds a DEPEND on
tetex, i understand that it needs a flag separate from "doc".
Thus, introducing "doc-printable" would solve that: it would
give its meaning back to "tetex", while still allowing packagers
to make dependency on TeX tools optionnal.
And for "doc-example", well, i don't have strong arguments for
that one, in most case it could fall under "doc-user" or
"doc-devel", depending if it's more about configuration examples
or code examples. That was more to stay a bit on-topic :)
Sure, introducing such flags would be a big work considering the
number of packages it would affects, but i don't think that would
be a problem: there would be absolutly no urgency to do it since
it doesn't touch packages functionnalities, so that's something
that could simply be changed when you're editing an ebuild for
another better reason.
Comments, flames?
--
TGL.
--
[email protected] mailing list
