On Thu, Oct 26, 2000 at 04:03:07PM -0600, Jason Gunthorpe wrote:
> On Fri, 27 Oct 2000, Anthony Towns wrote:
> > I don't really see what's so "middle ground" about it; it needs much more
> > significant changes to maintainer scripts [0], creates a compatability
> > problem, and doesn't really seem to buy anyone anything over the simpler
> > solution.
> Nonsense.
You've partially addressed the first two issues, but I'm still yet to see any
reason for all the extra complication.
> > echo "Setting up emacsen-common to cope with emacs20." >&2
> > /usr/lib/emacsen-common/emacs-install emacs20 >/dev/null 2>&1
> vs:
> if [ x`which dpkg-log` != x ]; then
> DL_PIPE=dpkg-log --priority=low --pipe
> DL_LOW=dpkg-log --priority=low
> DL_HIGH=dpkg-log --priority=high
> [..]
> else
> DL_PIPE=cat
> DL_LOW=echo
> [..]
> fi
>
> [..]
>
> $DL_LOW "Setting up emacsen-common to cope with emacs20."
> /usr/lib/emacsen-common/emacs-install emacs20 2>&1 | $DL_PIPE
> $DL_HIGH "The world is going to end!"
>
> The top is totally boiler plate and can be written once and just included
> by the people who use it.
Which will kludge up postinsts from now to forever, be an extra source for bugs,
and make changing things in future awkward.
Compare and contrast to the usr/doc boilerplate, eg: when it goes away,
nothing will break, you'll merely have mixed documentation if you do
a partial upgrade. If the above boiler plate ever goes away, new .debs
will not be installable with an old dpkg.
> Other than the stuff at the top the changes are equal to the vicious hack
> of using FD 2 and supressing any the messages.
So, essentially you're saying "if you ignore <this bad ugly vicious hack>
it's no worse than the other idea". And that the extra flexibility isn't
actually useful for anyone. And that it's not any easier to roll out
or anything.
So how about some other ideas? Dan Jacobowitz suggested just sending
all postinst output to /var/log/dpkg.log or similar: frontends and what
not can make that a fifo if they feel a need, and otherwise, it'll just
work. In the meantime, it still requires changes to all packages. It
has the mildly bad point that minor typos can stuff things up majorly:
compare >/var/lib/dpkg.log with >>/var/log/dpkg.log, eg, or the odds
of random typoes and logs going to various random places in /var/log,
or not going anyhere.
Antother possibility would be to make a requirement like:
Maintainer scripts should report what they're doing to
standard output. [blah blah]
Packages that need to use standard output and/or standard input
for interaction or longer pieces of information should bracket
that interaction with
echo "BEGIN INTERACTIVE"
# interactive stuff goes here
echo "END INTERACTIVE"
[more blah blah]
Something to that effect would have the benefit of still being loggable,
requiring changes to only the packages that actually do interaction,
and when we shift to using debconf for interactivity the crufty parts
will be able to be completely done away with.
In the short term, debconf could support this by having
debconf-using-postinsts stderr go to the *real* standard out rather than
the real standard error, and have some echoes in appropriate places
somewhere. Or it might need to do some cleverer piping actually. I think
it could be managed though.
In the longer term, with dpkg support, the logging information and the
debconf interaction can probably be arranged to go to different places
with no ned to have some tacky but automatable way to separate it.
Worst case is that some random debconf cruft gets logged, if you haven't
upgraded debconf, or you see some weird "INTERACTIVE" messages as you
do an install. Using an up to date debconf and an up to date frontend
of some sort that does logging gets rid of both these issues.
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:
pgpjT1QwW8GC0.pgp
Description: PGP signature