| 1 |
the new texinfo-5.x series has rewritten makeinfo in perl. the main `info` |
| 2 |
program is still in pure C. |
| 3 |
|
| 4 |
when it comes to packages installing .info pages, it's largely limited to the |
| 5 |
GNU projects as the format has never really caught on. many of those projects |
| 6 |
also install man pages. |
| 7 |
|
| 8 |
personally, i've never found info pages usable. for most utils, the man pages |
| 9 |
or the --help output is sufficient, and for people doing heavy development, the |
| 10 |
online html manuals are significantly more useful. |
| 11 |
|
| 12 |
when it was pure C, i could live with it as it's only <1MiB and no real deps |
| 13 |
to speak of. now it's more like 3MiB, and pulls in 3 semi-uncommon additional |
| 14 |
perl packages (not to mention perl itself). |
| 15 |
|
| 16 |
it's in @system for two reasons: it provides `info` and `makeinfo`. the |
| 17 |
former is for reading info pages (i.e. RDEPEND) while the latter is used for |
| 18 |
generating info pages (i.e. DEPEND) when the tarball didn't ship with them |
| 19 |
pregenerated (they usually do). |
| 20 |
|
| 21 |
one option would be to make the makeinfo stuff into a USE flag so all the perl |
| 22 |
junk isn't pulled in by default. only the packages that actually generate |
| 23 |
info pages can DEPEND on that. |
| 24 |
|
| 25 |
it'd be simpler if we just dropped it altogether from @system. if people want |
| 26 |
`info`, they can `emerge` it themselves. if packages want `makeinfo`, they |
| 27 |
can DEPEND on it -- few fall into this category (<100 by a rough survey of |
| 28 |
random Gentoo installs). |
| 29 |
|
| 30 |
obviously my preference is for the latter. |
| 31 |
-mike |
Archives