public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Jason Stubbs <jstubbs@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Package notices
Date: Fri, 3 Sep 2004 21:47:21 +0900	[thread overview]
Message-ID: <200409032147.21905.jstubbs@gentoo.org> (raw)
In-Reply-To: <opsdq7vpyxr4biet@localhost>

On Friday 03 September 2004 23:00, Pablo Villalba wrote:
> We're trying to build the house without having the plans for it yet.
> What do we need to do here? Which kind of output would be useful? Imho
> maintaining regular output (maybe flushing it at the end of all the emerge
> process) AND logging it to some special logfile (errors being notices to
> syslog too) would do it.
> Once this is clear and agreed we could think of how we'd have to implement
> it.

Nick layed out half the plan already, although it may not have seemed like it 
- he's very curt but it's usually enough if you know the context.

On Friday 03 September 2004 14:10, Nicholas Jones wrote:
> 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.

This must happen so that there is absolutely no (chance of) effect on starting 
up messages that happen when starting and stopping daemons. Currently, the 
same functions are used for output.

> 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.)

Portage has the ability to enable/disable colour based on the terminal type 
and user's preference. Furthermore, if the output is being logged as well as 
going to screen, coloured and non-coloured versions of the output must be 
providable on demand.

> 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.

This is a simple design descision that fits in well with portage's current 
security model for merges.

> PORTAGE can then manipulate the log, perform notifications,
> and do whatever else is necessary to maintain that file around
> cleanings and other merges.

In other words, any processing done on the logs once they're written must be 
completely separate from the logging itself.

> ${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.

These just show further design possibilities within the above rules but it is 
open to whomever decides to implement it on the exact details.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list


  reply	other threads:[~2004-09-03 12:44 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 ` [gentoo-dev] Package notices Nicholas Jones
2004-09-03 14:00   ` Pablo Villalba
2004-09-03 12:47     ` Jason Stubbs [this message]
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=200409032147.21905.jstubbs@gentoo.org \
    --to=jstubbs@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