[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PROPOSAL: dpkg-logger and related



Martin clearly understands what I'm talking about.  He has answered
almost exactly the way I would have (if not better).


On 8 Jan 1999, Martin Bialasinski wrote:
> 
> >> "BC" == Ben Collins <bmc@visi.net> writes:
> 
> BC> On Fri, Jan 08, 1999 at 12:08:34PM +0000, Jules Bean wrote:
> 
> BC> Having all these FD's or even just stdout/stderr might be a little
> BC> more overhead than it sounds. The package maintainer would have to
> BC> write extra code in the script in order to accomodate the extra
> BC> output he needs to send to.
> 
> What change is necessary to output to stderr in a sh script ? Is it
> that difficult (I practically know nil about shell programming)?
> stdout is easy, as you don't have to change anything. I just know
> perl, and this is plain easy in perl.
> 

echo "STDERR message" >&2
echo "FD 3 message" >&3
echo "FD 4 message" >&4

Umm.. that might be a bashism, I don't know if it's POSIX off-hand.
Obviously were this implemented, we'd have a couple of explanatory
examples in policy or the dev-ref.  A LINUXism approach is

echo "FD 3 message" > /dev/fd/3

> BC> Dpkg would also have to be patched up a great deal and this still
> BC> doesn't even cover where the logging should go. If the logging is
> BC> internal in dpkg, that's one more thing to break under dpkg, and
> BC> one more thing that can't be seperated from it. There would be no way
> BC> for alternate logging solutions to be enabled.
> 
> There is. dpkg would catch the output and feed it to the prefered
> dpkg-logger. So basically, the result is like calling dpkg-logger
> directly, but without the need to change the *inst scripts.

Exactly.

Although, we would in fact need to change the inst scripts, probably.  I
suspect we will need to do that for any full solution to this problem.
However, I prefer the concept that the scripts only need to make a very
simple decision as the 'importance' of the message, and then the detail
disposition of the message is centrally controlled.  I.e. no long complex
command lines in the actual scripts - perhaps triggering later huge mass
alterations when we realise we got something wrong.

For example, we'd be able to do

dpkg -i --log-quiet *.deb
dpkg -i --log-to-stdout *.deb
dpkg -i --log-to-pipe '/usr/local/bin/MyLogProgram' *.deb

And in general, the enclosing program (dselect or apt) would do the
'right' thing with the messages based on user preferences.

Jules

/----------------+-------------------------------+---------------------\
|  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd	       |
|  Jules aka     | jules@debian.org              |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/


Reply to: