1 |
I recently had a user write to me after banging his head against the |
2 |
wall for a while, trying to get a package working. By the time he wrote |
3 |
me, he had already figured it out, but he wanted to convey to me that |
4 |
what finally helped was actually the emerge output (which stated exactly |
5 |
how to get things working - in this case, the need to run emerge |
6 |
--config). He had not noticed this before and only saw it upon |
7 |
re-installing, given the transient nature of the emerge messages. |
8 |
|
9 |
Bottom line here is that there is extremely valuable and critical info |
10 |
in our emerge output. In a way, these messages are like Gentoo-specific |
11 |
READMEs (or release notes and/or install instructions). However, it is |
12 |
not saved for a user to use as a resource later (well, except that it is |
13 |
partially saved in the master emerge.log, but that's not quite useful |
14 |
enough). There is no "official" place to go to look for Gentoo |
15 |
instructions; /usr/share/doc is one logical place, but it only contains |
16 |
files actually installed, not the notes output by emerge (and these are |
17 |
usually upstream-supplied, not Gentoo). |
18 |
|
19 |
I propose that, upon merging a package, we save the emerge messages in |
20 |
either: 1) a package-specific file that resides somewhere "official" or |
21 |
2) in the portage DB, so that the messages can be re-read via a portage |
22 |
utility. In the latter case, either a new option to "equery" or a new |
23 |
"q" command (e.g. "equery readme <pkg>" or "qreadme <pkg>" could |
24 |
retrieve the text). |
25 |
|
26 |
In either case, there would then be a place to go that is known and |
27 |
consistent (and can be documented in the Gentoo doc). It could, in |
28 |
essense, serve as a kind of "Gentoo package README" collection. I could |
29 |
also imagine later expanding on this by letting a given package also |
30 |
include more thorough README info from a file if the maintainer so desires. |
31 |
|
32 |
-Joe |