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