1 |
Thanks for the reply Daniel |
2 |
|
3 |
I personally don't have the time to chase this down and spec it out, |
4 |
but hopefully someone else on the list would pick up the ball and take |
5 |
it! It seems like something that could be done with minimal intrusion |
6 |
to portage itself (adding a couple of calls to einfo and ewarn, and a |
7 |
mechanism to check at the end to any messages). |
8 |
|
9 |
Ideally it would be nice to be able to see this stuff before the actual |
10 |
emerge as well, so it might not even have to be that involved ... |
11 |
likely more like stashing the pkglist aside, and then doing a quick |
12 |
parse for einfo/ewarn and displaying would suffice. Maybe it could |
13 |
even be something in userland as opposed to portage itself ala |
14 |
gentoolkit. |
15 |
|
16 |
Hope someone can pick up the ball on this stuff, would be great to see! |
17 |
|
18 |
Mark |
19 |
|
20 |
On 13-Apr-04, at 10:51 AM, Daniel Robbins wrote: |
21 |
|
22 |
> |
23 |
>> I think Gentoo should really look at the way ewarn and einfo |
24 |
>> happen .... they don't do much good at all if you are |
25 |
>> installing more than one thing. I for one would _love_ to |
26 |
>> see them all show up at the end of the emerge along with the |
27 |
>> pkg that they belong with (in the case of long emerges). |
28 |
>> There are a lot of false bugs (I've registered a couple |
29 |
>> myself) due to this fact. |
30 |
> |
31 |
> I totally agree and have been hoping for a long time that we would have |
32 |
> something like this for Portage. I think it has been needed for several |
33 |
> years. I think the only reason it has not been added is because our |
34 |
> Portage |
35 |
> team is inundated with requests for new functionality and thus doesn't |
36 |
> always have the time to add this kind of stuff (too many |
37 |
> distractions.) But |
38 |
> this seems to be changing as carpaski gets more people up to speed on |
39 |
> the |
40 |
> internals of Portage development, and our APIs become more |
41 |
> standardized so |
42 |
> more people can work on the code simultaneously. |
43 |
> |
44 |
>> Most times you have to either a) log the entire build and go |
45 |
>> through it by hand to figure out if there was crucial info |
46 |
>> that you missed or b) go back after the fact and manually |
47 |
>> look at any ebuilds that were installed to see if there are |
48 |
>> in fact ewarn's or einfo's in them. |
49 |
> |
50 |
> Yes, this is a basic usability deficiency in Portage. I envision some |
51 |
> kind |
52 |
> of "info |
53 |
> Channel" added to Portage. Ebuilds can inject text files into the info |
54 |
> channel. They will then show up at the end of the merge, or Portage |
55 |
> will |
56 |
> display a message like this after it has run: |
57 |
> |
58 |
> There are 3 important package configuration messages you have not yet |
59 |
> read. |
60 |
> Type "emerge pkginfo" to read them. |
61 |
> |
62 |
> (Just like how it says how many files in /etc need updating.) |
63 |
> |
64 |
>> This is kinda sucky, and it's probably been beaten to death |
65 |
>> before, but here we go again ;) |
66 |
> |
67 |
> I know the feeling. Best thing to do would be to contact carpaski and |
68 |
> see if |
69 |
> we can get this on the roadmap. Maybe doing a written specification of |
70 |
> how |
71 |
> this feature should work (like an expansion on what I have above) |
72 |
> would be |
73 |
> helpful. You could also GLEP it. I know you would get lots of support |
74 |
> for |
75 |
> this idea -- someone just needs to sit down and architect a clear, |
76 |
> written |
77 |
> plan to explain how it would all work. For example, what command is |
78 |
> used by |
79 |
> an ebuild to "inject" a text file into the info channel? What emerge |
80 |
> option |
81 |
> is used to view the infochannel messages? What does emerge call |
82 |
> ($PAGER?) to |
83 |
> display the infochannel messages? Once all those little details are |
84 |
> agreed |
85 |
> upon, actual implementation should be relatively easy. |
86 |
> |
87 |
> Regards, |
88 |
> |
89 |
> Daniel |
90 |
> |
91 |
> |
92 |
> -- |
93 |
> gentoo-security@g.o mailing list |
94 |
> |
95 |
> |
96 |
===================================== |
97 |
Mark Guertin |
98 |
Technology Manager, Bruce Mau Design |
99 |
197 Spadina Ave, Suite 501 |
100 |
Toronto, ON, Canada M5T 2C8 |
101 |
guertin@××××××××××××××.com |
102 |
416-260-5777 ext. 291 |
103 |
===================================== |
104 |
|
105 |
|
106 |
This email and its attachments are confidential: they are for use of the |
107 |
named recipient(s) only. Information contained in this email and |
108 |
attachments to it are protected by privilege, work product immunity, |
109 |
copyright and other applicable law. If you are not the intended |
110 |
recipient please notify us immediately by telephone at 416.260.5777 or |
111 |
by e-mail at studio@××××××××××××××.com and delete this email from your |
112 |
files. |
113 |
|
114 |
|
115 |
-- |
116 |
gentoo-security@g.o mailing list |