Re: [gentoo-security] ewarn/einfo behavior (was Samba Testing Help)

[Mark Guertin]

Thanks for the reply Daniel

I personally don't have the time to chase this down and spec it out, 
but hopefully someone else on the list would pick up the ball and take 
it!  It seems like something that could be done with minimal intrusion 
to portage itself (adding a couple of calls to einfo and ewarn, and a 
mechanism to check at the end to any messages).

Ideally it would be nice to be able to see this stuff before the actual 
emerge as well, so it might not even have to be that involved ... 
likely more like stashing the pkglist aside, and then doing a quick 
parse for einfo/ewarn and displaying would suffice.  Maybe it could 
even be something in userland as opposed to portage itself ala 
gentoolkit.

Hope someone can pick up the ball on this stuff, would be great to see!

Mark

On 13-Apr-04, at 10:51 AM, Daniel Robbins wrote:

>
>> I think Gentoo should really look at the way ewarn and einfo
>> happen .... they don't do much good at all if you are
>> installing more than one thing.  I for one would _love_ to
>> see them all show up at the end of the emerge along with the
>> pkg that they belong with (in the case of long emerges).
>> There are a lot of false bugs (I've registered a couple
>> myself) due to this fact.
>
> I totally agree and have been hoping for a long time that we would have
> something like this for Portage. I think it has been needed for several
> years. I think the only reason it has not been added is because our
> Portage
> team is inundated with requests for new functionality and thus doesn't
> always have the time to add this kind of stuff (too many
> distractions.) But
> this seems to be changing as carpaski gets more people up to speed on
> the
> internals of Portage development, and our APIs become more
> standardized so
> more people can work on the code simultaneously.
>
>> Most times you have to either a) log the entire build and go
>> through it by hand to figure out if there was crucial info
>> that you missed or b) go back after the fact and manually
>> look at any ebuilds that were installed to see if there are
>> in fact ewarn's or einfo's in them.
>
> Yes, this is a basic usability deficiency in Portage. I envision some
> kind
> of "info
> Channel" added to Portage. Ebuilds can inject text files into the info
> channel. They will then show up at the end of the merge, or Portage
> will
> display a message like this after it has run:
>
>   There are 3 important package configuration messages you have not yet
> read.
>   Type "emerge pkginfo" to read them.
>
> (Just like how it says how many files in /etc need updating.)
>
>> This is kinda sucky, and it's probably been beaten to death
>> before, but here we go again ;)
>
> I know the feeling. Best thing to do would be to contact carpaski and
> see if
> we can get this on the roadmap. Maybe doing a written specification of
> how
> this feature should work (like an expansion on what I have above)
> would be
> helpful. You could also GLEP it. I know you would get lots of support
> for
> this idea -- someone just needs to sit down and architect a clear,
> written
> plan to explain how it would all work. For example, what command is
> used by
> an ebuild to "inject" a text file into the info channel? What emerge
> option
> is used to view the infochannel messages? What does emerge call
> ($PAGER?) to
> display the infochannel messages? Once all those little details are
> agreed
> upon, actual implementation should be relatively easy.
>
> Regards,
>
> Daniel
>
>
> --
> gentoo-security@g.o mailing list
>
>
=====================================
Mark Guertin
Technology Manager, Bruce Mau Design
197 Spadina Ave, Suite 501
Toronto, ON, Canada M5T 2C8
guertin@××××××××××××××.com
416-260-5777 ext. 291
=====================================


This email and its attachments are confidential: they are for use of the
named recipient(s) only. Information contained in this email and 
attachments to it are protected by privilege, work product immunity, 
copyright and other applicable law. If you are not the intended 
recipient please notify us immediately by telephone at 416.260.5777 or 
by e-mail at studio@××××××××××××××.com and delete this email from your 
files.


--
gentoo-security@g.o mailing list