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

Re: RFC: allow output from maintainer scripts



On Tue, Oct 24, 2000 at 04:16:02PM -0700, Joey Hess wrote:
> Anthony Towns wrote:
> If we modify policy to say this kind of thing should be done, I'd really
> like to see it happen via some kind of mechanism that can easily let it
> be stored in a log. I know this has been discussed in the past,
> inconclusively but maybe it's time to revisit it.

stdout? stderr?
 
> > > > So, how about something like:
> > > > 	Packages should briefly report the main tasks as they undertake
> > >                  may
> > Policy's about ensuring consistency amongst packages. "should" seems
> > appropriate here, just as it does for the manpage requirement.
> So what if the "main task" my postinst does is something utterly
> trivial. "Setting up /usr/doc symlink.. done." There is a wording
> problem with what you proposed.

Hmmm. "major" ? "significant" ?

On Tue, Oct 24, 2000 at 05:42:40PM -0600, Jason Gunthorpe wrote:
> On Tue, 24 Oct 2000, Joey Hess wrote:
> > If we modify policy to say this kind of thing should be done, I'd really
> > like to see it happen via some kind of mechanism that can easily let it
> > be stored in a log. I know this has been discussed in the past,
> > inconclusively but maybe it's time to revisit it.
> I think that if policy is going to be changed we should somehow make it so
> that these informational messages can be 
>   a) plain text, single line type format (ie no blocks of text)
>   b) no user input
>   c) Output to a file descriptor indicated by an environment variable,
>      or stdout by default.
> Then perhaps someday one of the APT front ends can show worthwhile output,
> log it, etc.

(c) would be a pain to cope with in maintainer scripts, probably.

Using stdout is current practice and quite convenient, but apt frontends
then can't distinguish between random prompty stuff, and these note things.

That's not necessarily a bad thing: it'd mean that all the questions and
informative notes would get logged too. OTOH, it'd mean some of the formating
would get stuffed up, questions wouldn't have their answers included,
long boring stuff from MTA postinsts would clutter up the logs, and debconf
using postinsts would look very weird.

In the longer term, it may well interfere with the debconf worldview
as well.

So I can't see any way of making this work with stdout and current
practice.

So is there anything wrong with just consistently using stderr for these
notes?

That'd make the text look something like:

	The package installation scripts should record any significant
	activities they undertake to standard error. For example:

		echo >&2 "Symlinking /var/mail to /var/spool/mail."
		ln -sf spool/mail /var/mail

		/etc/init.d/sysklogd restart >&2

	Messages should be formatted in a similar manner to those generated
	by the various init scripts. If an operation is expected to take
	some time, you may indicate this with something like:

		echo -n >&2 "Bytecompiling for emacs20"
		# ... code to byte compile ...
		echo >&2 "."

	The package installation scripts should avoid producing output
	which is unnecessary for the user to read or overly verbose. This
	means, amongst other things, using the `--quiet' option on
	`install-info'.

	If a package has a vitally important...

	Packages should try to minimize the amount of prompting...

This would require lots of changes to packages.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgp4sYar66Jnu.pgp
Description: PGP signature


Reply to: