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

[Bernd Pachur]

That's a rather good idea!

Especially as there are ebuilds like linux-wlan-ng that can only be
successfully emerged with FEATURES="-sandbox -userpriv" and you will
only get this info at the end of a successfull emerge. But since you do
not know of this requirement you will never get to that point because
the ebuild will fail with some error message without printing the einfo
or ewarn part.

cheers,
bernd

On Tue, 2004-04-13 at 18:51, Mark Guertin wrote:
> 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
-- 

Text mails preferred!
No HTML-mail please!
Encrypted mails preferred!