Re: PROPOSAL: dpkg-logger and related
>> "BC" == Ben Collins <bmc@visi.net> writes:
BC> On Fri, Jan 08, 1999 at 12:08:34PM +0000, Jules Bean wrote:
>> As I and someone else (Martin, I think) pointed out when you first
>> proposed it, a far cleaner solution is simply to redirect stdout, stderr
>> and perhaps a few more FDs from the scripts. This minimises the amount of
>> changes which need to made to the scripts, and makes them simpler to
>> write. Then apt 'does the right thing' with the FDs - and what it does
>> with the FDs would cover the same gamut of possibilities as the options
>> you have in dpkg-logger, and maybe more.
BC> apt has no direct contact with package installs. So it can't do
BC> anything like this.
apt calls dpkg. dpkg does the logging. apt could just install a
logging method it wants to use as default before starting to call dpkg
-i. Afterwards it would reset the dkpg-logger method to the one
activated before.
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.
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.
Ciao,
Martin
Reply to: