public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Frank Schafer <frank.schafer@t-systems.cz>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Portage log suggestion
Date: Mon, 12 Sep 2005 15:35:47 +0200	[thread overview]
Message-ID: <1126532147.5947.200.camel@localhost.localdomain> (raw)
In-Reply-To: <20050912130129.GC29046@nightcrawler>

On Mon, 2005-09-12 at 08:01 -0500, Brian Harring wrote:
> On Mon, Sep 12, 2005 at 02:13:43PM +0200, Frank Schafer wrote:
> > Hi,
> > 
> > I fought with a stage1 install during this weekend. Today in the morning
> > I succeeded.
> > I had to move a lot in /var/log/portage.
> > 
> > For the content of this directory I'd suggest the following:
> > 
> > Remove the 4 digit number from the log file names.
> They're relevant to portage stable; down the line it'll likely be 
> mtime based.
> Right now that 4 digit number is an internal incrementing counter 
> that's tagged into the log file name.

I realized that. My suggestion was to NOT tag it there. It is more
annoying for the person who has to work with this directory. I know
there are a lot of gensomething tools but they don't do anything else
than duplicate the functionality of ``ls'' in this case. Leave it
simple!

> 
> > It is a good idea to have 2 files for each package. One with the output
> > of make and one with the messages for the installer. Name the former
> > package-version.log and the latter package-version.msg
> 
> Doesn't work that way, and what you're after (restating your 
> 'installer' as enotice/ewarn/einfo) is elog, something that'll be in 
> the next major version.

No, :D my installer is the person who installs the system :)

> 
> You're seeing two logs due to the fact you have FEATURES="buildpkg" 
> on; effectively, portage build's the binpkg (log 1), then merges it 
> (log 2).  This is inneficient though, since it builds up one $IMAGE 
> dir, binpkg's it, then dumps it to another dir and installs from that.
> 
> That's an old annoyance that should die a miserable death soon enough.

Please don't say that you plan to make the only sense-making messages to
nearly dismiss within many mega log files :(

Having a special function for logging (elog) is a good thing. This
function could create the pkg.version.log (output of the build process -
mostly make) and pkg.version.msg (the notes which some packages write
out meant for people what to be aware of). Unfortunately I'm not so good
in Python and don't have much time. So I can't involve in direct
development. Maybe this will be better in half a year.

> ~harring

Regards
Frank

PS: That's not meant as critics - it's a suggestion (see the subject ;)
-- 
gentoo-dev@gentoo.org mailing list



      parent reply	other threads:[~2005-09-12 13:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 12:13 [gentoo-dev] Portage log suggestion Frank Schafer
2005-09-12 13:01 ` Brian Harring
2005-09-12 13:29   ` Thomas de Grenier de Latour
2005-09-12 13:35   ` Frank Schafer [this message]

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=1126532147.5947.200.camel@localhost.localdomain \
    --to=frank.schafer@t-systems.cz \
    --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