Re: dpkg.log reworked
On Fri, Jan 01, 1999 at 10:07:44AM -0800, Joseph Carter wrote:
> On Fri, Jan 01, 1999 at 12:48:24PM -0500, Ben Collins wrote:
> > > This still seems like you're trying to put wallpaper up over a hole in
> > > the wall to me.. I don't see how this really solves any of the problems
> > > with dpkg's interactivity or that sort of thing. At best ig gives you a
> > > way to see what the output of the installation was selectively. Arguably
> > > this is a good thing, a very good thing really. But this seems like the
> > > wrong way to do it.
> >
> > Theres, the problem. This is meant to solve interactivity problems. It's
> s/is/isn't/ I assume?
> > meant to solve the problem of too much info flying by on a PII 450 that
> > is shooting over 500 packages into the new system and to keep admins
> > from having to baby sit the machine during a 486 install for 3 hours
> > just see all the little tidbit (but sometimes very important) package
> > messages that go by.
>
> The ideal way to handle this IMO would be for apt to run do the logging
> and such. My apologies for misunderstanding the intent of your idea. I
> said before that logging the output of apt/dselect would be useful if it
> was optional. I realize that doing it this way DOES require mods to the
> dselect methods and to apt, but the mods to the dselect methods are easy
> enough and the mod to apt would be good for the sake of doing things the
> best way rather than the easiest.
The good thing is that dpkg/apt/dselect can use the same features.
Rewritting syslog type features would add a great deal of overhead into
these programs not only for maintaining the extra code but porting as
well (syslog already works well, is well developed, and tested across
platforms).
It also wouldn't be easy for dpkg and others to allow packages to talk
directly thru them in order to log messages, atleast not in decision making
instances (the package may not always want to log the message). It
would require an external utility (ie. dpkg-logger) that would actually
have to be almost exact in functionality to logger, which we already
have. It would also seperate package logging from the normal logging
features in the system, which IMO, is a bad move.
This is a Good Thing(r). We don't have to reimplement entire programs
in order to be innovative. Using the tools we already have _is_ a
better way, IMO.
--
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. bcollins@debian.org
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation
Reply to: