From: Nicholas Jones <carpaski@gentoo.org>
Cc: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: [gentoo-dev] Package notices
Date: Fri, 3 Sep 2004 01:10:38 -0400 [thread overview]
Message-ID: <20040903051038.GA11426@twobit.net> (raw)
In-Reply-To: <1094155935.19504.40.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
> Basically, it could be implemented using a new eclass or just adding the
> enotice function to eutils - I wouldn't want all the einfos logged,
> anyway. (patching notices? no thanks.)
> What I would like, would be messages from packages like cacti.
> enotice itself will write into the file and emit an einfo.
I mentioned what I would consider most acceptable at some point,
but no one appears to have seen that, so it must have gotten lost.
He's what needs to get done for this to work:
functions.sh (from baselayout) dependence needs to go away.
All used functions need to be logged/rewritten to not use those
functions, and instead maintain its own.
All said functions must be rewritten, for portage, with the
capability to handle colors and terminals and the like as
portage does currently. (People don't want ANSI in their logs.)
The output can be writting in any number of ways to a file in
${T} during the execution of the build. This does not violate
sandbox and is quite easy to find.
PORTAGE can then manipulate the log, perform notifications,
and do whatever else is necessary to maintain that file around
cleanings and other merges.
${T}/notices.${PF}.${TYPE}
would be perfectly fine as long as it was definitive/unique
to the particular package. Notices of all types could also
simply be prefixed. '*' '-' '!' or whatever seems best.
If you are so inclined, you could also write a parser for
these files that can designate priorities using color or
some other visual aid. (Keep in mind that it must be
deterministic through simple ascii as well for synthesisers.)
For multiple reasons, I prefer python for these tools.
There are many, many possibilities, but please follow
the outline provided here.
--NJ
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-09-03 5:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-02 20:12 [Fwd: Re: [gentoo-dev] Package notices] Eldad Zack
2004-09-02 22:17 ` Chris Gianelloni
2004-09-02 22:54 ` Thomas de Grenier de Latour
2004-09-03 5:10 ` Nicholas Jones [this message]
2004-09-03 14:00 ` [gentoo-dev] Package notices Pablo Villalba
2004-09-03 12:47 ` Jason Stubbs
2004-09-03 15:10 ` Eldad Zack
2004-09-03 14:15 ` Jason Stubbs
2004-09-03 16:15 ` Eldad Zack
2004-09-04 12:55 ` Eldad Zack
-- strict thread matches above, loose matches on Subject: below --
2004-09-01 19:42 Eldad Zack
2004-09-01 21:05 ` William Hubbs
2004-09-01 22:01 ` Thomas de Grenier de Latour
2004-09-02 16:46 ` purslow
2004-09-02 18:06 ` Anton Starikov
2004-09-02 19:59 ` N. Owen Gunden
2004-09-02 18:46 ` Christian Gut
2004-09-02 18:56 ` Alexander Gretencord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040903051038.GA11426@twobit.net \
--to=carpaski@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox