Re: RFC: allow output from maintainer scripts
On Mon, Oct 30, 2000 at 09:22:02AM +1100, Brian May wrote: I can't help but think though that this indicates a bigger problem in our reliance on maintainer scripts - it is not possible to add new features without: - hard-coding the entire feature in the maintainer script AND/OR - depending on another package which codes the feature. Not sure on the best solution. Here is one that comes to mind: Yes, this seems to be a general problem. How about the following solution? A bit messy, but might work, maybe with modifications. Have a distribution called upgrade-prereq (pointing to upgrade-prereq-woody initially) which contains the package upgrade-prereq and any *major* packages which are necessary for a significant number of packages from testing/unstable to work. These would have to be compiled on a stable system, so that they can be installed on a stable system. Then we would have to educate users (debian(-devel)-announce) that for partial upgrades, one must add the upgrade-prereq distribution to the /etc/apt/sources.list and install the package upgrade-prereq. This package would have versioned depends on all of the packages in the upgrade-prereq distribution. Examples of packages which would be suitable for the upgrade-prereq distribution: dpkg for such things as dpkg-log aptif a new version is needed to handle something special man-db for partial upgrades to potato (FHS issue) We could even make upgrade-prereq an essential package in the stable distribution which depends upon the correct versions of these packages, and somehow (how?) ensure that when upgrading the distribution, the upgrade-prereq package is upgraded first, pulling in the versions of the key packages needed for the upgrade. Does this sound at all reasonable? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: RFC: allow output from maintainer scripts
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony dpkg already knows this, and it can already be determined Anthony by looking for Unpacking ... or Setting up - current task for this package, as generated by dpkg-log Anthony Which is exactly what this would be outputting. Only the current dpkg task, not the current postinst task or (subtask to put it another way). - this list could highlight more important events based on the parameters based to dpkg-log. Anthony What events here are so important? Why even bother Anthony displaying the ones that aren't important? You seem to imply that a good system is one which generates no output, except for what package is being installed, and perhaps what state dpkg is in when installing it. Isn't this the very reason people hate Windows or Red-hat installation programs/scripts? - ie. you can't tell what is happening behind the scenes. At least, that is the impression I got listening to other people. I think a better system would be to let the user decide how much detailed information he wants to see, and to do this the program needs to be able to determine the priority of various messages. ie. similar to why priorities are needed for debconf. -- Brian May [EMAIL PROTECTED]
Re: RFC: allow output from maintainer scripts
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Which will kludge up postinsts from now to forever, be an Anthony extra source for bugs, and make changing things in future Anthony awkward. I don't think we should downgrade the capability of future debian products, either just for the sake of back-words compatibility. Anthony Compare and contrast to the usr/doc boilerplate, eg: when Anthony it goes away, nothing will break, you'll merely have Anthony mixed documentation if you do a partial upgrade. If the Anthony above boiler plate ever goes away, new .debs will not be Anthony installable with an old dpkg. Like the usr/doc situation, after a while we can get rid of the extra stuff. I can't help but think though that this indicates a bigger problem in our reliance on maintainer scripts - it is not possible to add new features without: - hard-coding the entire feature in the maintainer script AND/OR - depending on another package which codes the feature. Not sure on the best solution. Here is one that comes to mind: Perhaps some general system could be implemented that uses a feature straight away (if it is already installed) or takes some other action if the feature is not installed yet (eg ignoring the request or logging the request for latter in case the feature is installed). Such a mechanism could also be used as a base for update-* -- Brian May [EMAIL PROTECTED]
Re: RFC: allow output from maintainer scripts
(Please don't Cc: me on these mails) On Mon, Oct 30, 2000 at 09:07:38AM +1100, Brian May wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony dpkg already knows this, and it can already be determined Anthony by looking for Unpacking ... or Setting up - current task for this package, as generated by dpkg-log Anthony Which is exactly what this would be outputting. Only the current dpkg task, not the current postinst task or (subtask to put it another way). Eh? This entire thread's been about having the postinst output the current postinst task. - this list could highlight more important events based on the parameters based to dpkg-log. Anthony What events here are so important? Why even bother Anthony displaying the ones that aren't important? You seem to imply that a good system is one which generates no output, except for what package is being installed, and perhaps what state dpkg is in when installing it. Not even remotely. I'm not sure where you're getting this from at all. I think a better system would be to let the user decide how much detailed information he wants to see, and to do this the program needs to be able to determine the priority of various messages. Everything you've said previoulsy argues for outputting some information as to what's going on. I agree completely. Saying when you're starting services and what not is helpful. We've established that, I think. What afaict hasn't been established is any reason to prioritise these messages. Especially when prioritising them introduces extra complexity either by moderately complicated boiler plate code, or huge numbers of new dependencies. Who is actually helped by this to make the extra complexity worthwhile? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgp3JoTi27oX0.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
On Mon, Oct 30, 2000 at 09:22:02AM +1100, Brian May wrote: Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Which will kludge up postinsts from now to forever, be an Anthony extra source for bugs, and make changing things in future Anthony awkward. I don't think we should downgrade the capability of future debian products, either just for the sake of back-words compatibility. Just because we might choose not to add piles of cruft to our packages right now, doesn't mean we can't change our mind later. We're not downgrading anything. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpn8chQXOsio.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
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 21 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 21 | $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 [EMAIL PROTECTED] 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 pgpsJhNw1xekY.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
John == John Goerzen [EMAIL PROTECTED] writes: John I think that works well. It's better than requiring a John separate command, and in fact, one can redirect output of John commands to stderr anyway for those cases in which you might John want to log the output of an external program. Requiring John dpkg-log prevents that. IMHO using the dpkg-log helps structure the output of the task, and what make it easier to have a more professional looking GUI front end. eg such a program could have GUI fields for - current package - current task for this package, as generated by dpkg-log - scroll-able list with STDERR and STDOUT output (eg to catch shell scripting errors). This could be disabled if desired. - this list could highlight more important events based on the parameters based to dpkg-log. Now, if dpkg used a similar method to report directory not empty warnings, the GUI could even have an option that allows you to browse the directory, and see if there really is anything important there. Now, this E-Mail is going to open up a new can of worms ;-) -- Brian May [EMAIL PROTECTED]
Re: RFC: allow output from maintainer scripts
On Fri, Oct 27, 2000 at 07:53:06PM +1100, Brian May wrote: John == John Goerzen [EMAIL PROTECTED] writes: IMHO using the dpkg-log helps structure the output of the task, and what make it easier to have a more professional looking GUI front end. eg such a program could have GUI fields for - current package dpkg already knows this, and it can already be determined by looking for Unpacking ... or Setting up - current task for this package, as generated by dpkg-log Which is exactly what this would be outputting. - scroll-able list with STDERR and STDOUT output (eg to catch shell scripting errors). This could be disabled if desired. Which would break with debconf (stdout is either used for the confmodule protocol or for pretty guis). If we were willing to ignore debconf, we'd be able to just use stdout for the log messages, and everything'd be fine and dandy. - this list could highlight more important events based on the parameters based to dpkg-log. What events here are so important? Why even bother displaying the ones that aren't important? Yeesh. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpOhrQOCWjdY.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
Anthony Towns wrote: Using stdout is current practice and quite convenient, but apt frontends then can't distinguish between random prompty stuff, and these note things. 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 an alternative that has occurred to me is that we could introduce a command like dpkg-log and require that all output goes through it. dpkg-log Recalibrating the frobnitzer dpkg-log --long Bytecompiling for emacs20 dpkg-log --longdone Then dpkg-log could be replaced/coopted by these apt frontends you apeak of, and by debconf, so their dpkg-log versions actually handle the logging however they prefer to handle it. I'm not sure how things like apt-frontends could temporarily make their version be used, so this needs more thought. -- see shy jo
Re: RFC: allow output from maintainer scripts
Anthony Towns wrote: 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 ? significant sounds good to me. So is there anything wrong with just consistently using stderr for these notes? It just seems wrong -- stderr is meant for errors after all. But maybe I'm being needlessly pedantic. 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 . That's nice. -- see shy jo
Re: RFC: allow output from maintainer scripts
Jason Gunthorpe wrote: The standard version would simply have to use a technique like I described, you wouldn't want to be replacing programs basked on what front end is being used, that is messy. Oh, you mean make dpkg-log write to a fifo or something? -- see shy jo
Re: RFC: allow output from maintainer scripts
On Thu, 26 Oct 2000, Joey Hess wrote: Jason Gunthorpe wrote: The standard version would simply have to use a technique like I described, you wouldn't want to be replacing programs basked on what front end is being used, that is messy. Oh, you mean make dpkg-log write to a fifo or something? Yes, a unix domain socket, or pre-opened file FD, some mechanism passed in through an environment variable. We can set a reasonable format so we can tag messages w/ priority. The absense of such a variable would just echo to stdout. Randolph was working on a similar scheme for debconf at one point, IIRC he was going to use a unix socket (which is good for debconf) Jason
Re: RFC: allow output from maintainer scripts
On Tue, Oct 24, 2000 at 03:28:09PM -0700, Joey Hess wrote: Anthony Towns wrote: The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. Or 40 lines of garbage ralating to byte-compiling obscure emacs modules. Well, yes. Bytecompiling emacs modules: emacs19 emacs20 xemacs20 would be useful output, by comparison. Anything would be useful by comparison (and let's not even talk about the packages that spew tex output to the screen and what users think about that). But consider: one of these emacs packages is installing and it byte-compiles ok. Why should we display the message? Remember staving off boredom is not an answer. I think this is something a user should be able to decide, and not dictated to him by Debian. Ideally you would be able to set the level of details you want to see, and policy only defines a couple of extreme levels (no output at all, verbose == everything) and leaves the medium levels to the package maintainers. The level should be passed to the install script by dpkg (or via environment, also by dpkg or by user). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: RFC: allow output from maintainer scripts
On Fri, 27 Oct 2000, Anthony Towns wrote: This means future debs can't be installed with the current dpkg. It means future dpkg's can never output anything. It means all debs that do anything important in their postinst need an --assert-somethingorother in their preinst. Seems like needless complexity to me. Well, the changes to dpkg are already propelling us to this eventuality and there is no migration plan. Why don't we make one, and solve these problems too? Jason
Re: RFC: allow output from maintainer scripts
On Thu, Oct 26, 2000 at 01:33:34PM -0600, Jason Gunthorpe wrote: On Fri, 27 Oct 2000, Anthony Towns wrote: This means future debs can't be installed with the current dpkg. It means future dpkg's can never output anything. It means all debs that do anything important in their postinst need an --assert-somethingorother in their preinst. Seems like needless complexity to me. With emphasis on the needless. Well, the changes to dpkg are already propelling us to this eventuality and there is no migration plan. Why don't we make one, and solve these problems too? We already have a migration plan for incompatible changes to dpkg: use --assert-somethingorother in the preinst. This seems to have worked relatively okay for predepends and epochs. Versioned provisions seem like a fairly similar addition that will be able to be handled in much the same way. Was there something else you were referring to? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpDXrBRs1nme.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
On Fri, 27 Oct 2000, Anthony Towns wrote: This means future debs can't be installed with the current dpkg. It means future dpkg's can never output anything. It means all debs that do anything important in their postinst need an --assert-somethingorother in their preinst. Seems like needless complexity to me. With emphasis on the needless. I think it is important, hardly needless. Why don't we make one, and solve these problems too? We already have a migration plan for incompatible changes to dpkg: use --assert-somethingorother in the preinst. This seems to have worked We haven't had to use something like that in a long time. I don't think it will be as effective these days. like a fairly similar addition that will be able to be handled in much the same way. Was there something else you were referring to? The upgrade problems with versioned provides can't be handled by a --assert thingy, dpkg and apt will have to be upgraded to versions that understand them before they can be safely used at all. At least with the dpkg-log idea it is fairly easy to have compatibility, a couple lines of shell script will do it just fine. Jason
Re: RFC: allow output from maintainer scripts
On Thu, Oct 26, 2000 at 08:06:58PM +0200, Marcus Brinkmann wrote: Or 40 lines of garbage ralating to byte-compiling obscure emacs modules. Well, yes. Bytecompiling emacs modules: emacs19 emacs20 xemacs20 would be useful output, by comparison. Anything would be useful by comparison (and let's not even talk about the packages that spew tex output to the screen and what users think about that). I think this is something a user should be able to decide, and not dictated to him by Debian. But until that's implemented, the default shouldn't be displaying half the bible for each emacs|tex-using package. :) -- Digital Electronic Being Intended for Assassination and Nullification
Re: RFC: allow output from maintainer scripts
On Thu, Oct 26, 2000 at 02:21:06PM -0600, Jason Gunthorpe wrote: On Fri, 27 Oct 2000, Anthony Towns wrote: This means future debs can't be installed with the current dpkg. It means future dpkg's can never output anything. It means all debs that do anything important in their postinst need an --assert-somethingorother in their preinst. Seems like needless complexity to me. With emphasis on the needless. I think it is important, hardly needless. Perhaps you could provide some examples where it'd be particularly useful, then. I find it hard to believe that this thread can reasonably go from there's no need for output at all for any reason to there's a need for so much output that we must be able to categorise it and filter it, and to hell with backwards compatability. Why don't we make one, and solve these problems too? We already have a migration plan for incompatible changes to dpkg: use --assert-somethingorother in the preinst. This seems to have worked We haven't had to use something like that in a long time. I don't think it will be as effective these days. You'll be unable to install the .deb until your dpkg correctly supports versioned provides (the preinst would fail), and apt won't have any idea how to do the upgrade. This seems about exactly the same as previously. like a fairly similar addition that will be able to be handled in much the same way. Was there something else you were referring to? The upgrade problems with versioned provides can't be handled by a --assert thingy, dpkg and apt will have to be upgraded to versions that understand them before they can be safely used at all. dpkg already correctly fails on unimplemented --asserts. Apt simply has no way of automatically coping when it's existing algorithm fails. [0] Cheers, aj [0] One possibility might be having Apt try to just ignore all the stanzas it can't understand and try to upgrade itself if it finds the Packages file too complicated to cope with. This means that apt, and things it depends on can't use complicated things that apt can't cope with, just as dpkg can't really rely on pre-depends. -- Anthony Towns [EMAIL PROTECTED] 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 pgp8dRCeSZMRF.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
On Fri, 27 Oct 2000, Anthony Towns wrote: I find it hard to believe that this thread can reasonably go from there's no need for output at all for any reason to there's a need for so much output that we must be able to categorise it and filter it, and to hell with backwards compatability. No, the current situation has alot of output and this thread started because people want to see less - managing the output we already have seems to be a reasonable middle ground. We haven't had to use something like that in a long time. I don't think it will be as effective these days. You'll be unable to install the .deb until your dpkg correctly supports versioned provides (the preinst would fail), and apt won't have any idea how to do the upgrade. This seems about exactly the same as previously. Er, I ment that using --asserts create confusing problems for the end user and preclude any possibility of a safe automatic upgrade. It is fortunate APT's ordering algorithms 'get lucky' and tend to install dpkg early on in the process - otherwise doing this would create a huge mess. As it is now APT aborts on versioned provides so the user has a clear indication they need to upgrade stuff. It could do it more elegently, but thats what we have shrug. [BTW, I haven't seen V-P's pass through policy, and I haven't seen a spec for them. APT still does not parse them..] [0] One possibility might be having Apt try to just ignore all the stanzas it can't understand and try to upgrade itself if it finds the Packages This is a solution I have been contemplating for a while, I'm not sure how well it will work overall. It does sound good.. Jason
Re: RFC: allow output from maintainer scripts
On Thu, Oct 26, 2000 at 03:16:00PM -0600, Jason Gunthorpe wrote:
On Fri, 27 Oct 2000, Anthony Towns wrote:
I find it hard to believe that this thread can reasonably go from
there's no need for output at all for any reason to there's a need
for so much output that we must be able to categorise it and filter it,
and to hell with backwards compatability.
No, the current situation has alot of output and this thread started
because people want to see less - managing the output we already have
seems to be a reasonable middle ground.
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.
You'll be unable to install the .deb until your dpkg correctly supports
versioned provides (the preinst would fail), and apt won't have any idea
how to do the upgrade. This seems about exactly the same as previously.
Er, I ment that using --asserts create confusing problems for the end user
and preclude any possibility of a safe automatic upgrade.
AFAICT, it's always *safe*, it's just that apt can't necessarily manage to
do everything for you *automatically*, and may require manual assistance
(by aborting halfway through) at (unpredicatable) times.
To fix this forever, we have to accurately predict all the sorts of
changes we'll ever make. Personally, I doubt that's possible.
Hmmm. Apart from the fact that dpkg and apt don't talk to each other about
ordering and failure issues to well, there needn't be a problem with a
preinst failing, need there? ie dpkg/apt sould be able to just finish
configuring the other stuff, and send a Hey! This needs attention!
report of some kind to the admin.
This is going a bit off topic...
Cheers,
aj
[0] Compare say:
echo Setting up emacsen-common to cope with emacs20. 2
/usr/lib/emacsen-common/emacs-install emacs20 /dev/null 21
with, say (using the given API to display all the existing info in
a filterable manner):
dpkg-log () {
if [ -e /usr/bin/dpkg-log ]; then
/usr/bin/dpkg-log $@
else
echo $@
fi
}
dpkg-log Setting up emacsen-common to cope with emacs20.
/usr/lib/emacsen-common-common/emacs-install emacs20 |
while read line; do
dpkg-log --priority=low $line
done
--
Anthony Towns [EMAIL PROTECTED] 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
pgpfGb82uM37L.pgp
Description: PGP signature
Re: RFC: allow output from maintainer scripts
Anthony Towns wrote:
dpkg-log Recalibrating the frobnitzer
This means future debs can't be installed with the current dpkg. It
means future dpkg's can never output anything. It means all debs that do
anything important in their postinst need an --assert-somethingorother
in their preinst. Seems like needless complexity to me.
We don't need a --assert.
if [ ! -x /usr/bin/dpkg-log ]; then
eval 'dpkg-log () {
while expr $1 : -; do
shift
done
echo $*;
}'
fi
And if that is too much verbiage, all that is needed is a depends on
whatever package provides dpkg-log. --assert is not intended for this
kind of thing.
--
see shy jo
Re: RFC: allow output from maintainer scripts
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. echo Setting up emacsen-common to cope with emacs20. 2 /usr/lib/emacsen-common/emacs-install emacs20 /dev/null 21 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 21 | $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. Other than the stuff at the top the changes are equal to the vicious hack of using FD 2 and supressing any the messages. Jason
Re: RFC: allow output from maintainer scripts
Anthony Towns aj@azure.humbug.org.au writes: So is there anything wrong with just consistently using stderr for these notes? I think that works well. It's better than requiring a separate command, and in fact, one can redirect output of commands to stderr anyway for those cases in which you might want to log the output of an external program. Requiring dpkg-log prevents that. -- John
Re: RFC: allow output from maintainer scripts
On Thu, Oct 26, 2000 at 02:43:32PM -0700, Joey Hess wrote:
Anthony Towns wrote:
dpkg-log Recalibrating the frobnitzer
This means future debs can't be installed with the current dpkg. It
means future dpkg's can never output anything. It means all debs that do
anything important in their postinst need an --assert-somethingorother
in their preinst. Seems like needless complexity to me.
We don't need a --assert.
You need an assert, a dozen lines of boilerplate code, or versioned
dependencies on an essential package for every package with a
significant postinst, and versioned predependencies for every package
with a significant preinst, for as long as we want to support upgrades
from anything pre-woody (and by support that just means don't have
things break in a confusing manner).
if [ ! -x /usr/bin/dpkg-log ]; then
eval 'dpkg-log () {
while expr $1 : -; do
shift
done
echo $*;
}'
fi
Note that this code doesn't cope with the --pipe option that Jason was
blithely assuming.
And all this for _what_?
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] 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
pgpDE4p1YcLVm.pgp
Description: PGP signature
Re: RFC: allow output from maintainer scripts
The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. To me, those sorts of outputs seem useful and helpful, so I think policy should probably explicitly allow for them, or at least not forbid them as it apparently does atm. Some comments would be appreciated. There are some packages that print things like: Checking nobody UID 65534 Checking that the system works YES! Checking where is the kitchen. THERE!! That kind of output should be forbidden, and maintainers should be punished.. =b
Re: RFC: allow output from maintainer scripts
[EMAIL PROTECTED] (Joey Hess) wrote on 24.10.00 in [EMAIL PROTECTED]: Brian May wrote: How about something like this: Messages should only be displayed on the console if: - it represents a slow task, eg compiling modules (emacs) or compiling ls-R files (latex). Of course, this is a subjective criteria... What is a slow task? Policy explictly says you should NOT output things to stave off boredom on the part of a user. Displaying stuff for tasks that may be slow on my 386 clearly falls under that. I'd use that description for outputting dots, and even then I'd be pretty doubtful about that requirement. This is not to stave off boredom, this is to explain what the hell is taking so long. - it represents a task that alters the state of the computer, eg starting a daemon, or changing a config file. Obviously, this could be debated... Nearly everything a postinst script does alters the state of the computer. Still, *some* of those changes (like starting demons) are important. MfG Kai
Re: RFC: allow output from maintainer scripts
This would require lots of changes to packages. so we change lots of packages. Debian is being used by IS more and more these days. At VA alone we have some 100+ Debian machines now. The current package setup makes this a headache for updates. Being able to log output and ensure that the user will not have to smack enter every few minutes would go a long way. I would love for Debian to be able to go to LISA (Large Install Sys Admin Conference) and hold its head up. Fighting change because we will have to modify a good part of debian is no excuse. Debian has a long history of doing the technically correct thing even if it meant some hard work. We went from dselect to apt, the addition of debhelper, the growth of debconf, dinstall is being changed, etc. All for the better. I know that I am asked for a way to log package output EVERY tradeshow and whenever there are more than 3 debian users in a room. Most everyone wants to have apt-get upgrade in a cron job.
RE: RFC: allow output from maintainer scripts
The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. To me, those sorts of outputs seem useful and helpful, so I think policy should probably explicitly allow for them, or at least not forbid them as it apparently does atm. during an install of more than say 3 packages, all that output gets washed away. Especially for the many people who do updates from term windows in X. The output of most packages boil down to debug messages. I am not against letting the sysadmin know what is happening. Perhaps we just need a better way to handle it.
Re: RFC: allow output from maintainer scripts
Anthony Towns wrote: The first paragraph of that section states: ``The package installation scripts should avoid producing output which it (sic) is unnecessary for the user to see and should rely on `dpkg' to stave off boredom on the part of a user installing many packages. [...]'' The fourth paragraph continues: ``If a package has a vitally important piece of information to pass to the user [...] it should display this in the `postinst' script and prompt the user to hit return to acknowledge the message.'' Hmmm. I'm not actually sure this conclusion makes sense now. Joey, am I mis-stating something? (It seems to me there's a difference between necessary output, which can be displayed, and vitally important output, which must pause the installation) Well I'd never really read those two paragraphs side by side I must confess. I suppose it can be read that way. Since old policy doesn't have rationalles and that has been in it forever, it's hard to say if this is intentonal or just a poor choice of words. The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. Or 40 lines of garbage ralating to byte-compiling obscure emacs modules. To me, those sorts of outputs seem useful and helpful Some of them, a lot are massively useless debug output. -- see shy jo
Re: RFC: allow output from maintainer scripts
On Tue, Oct 24, 2000 at 10:56:50AM -0700, Joey Hess wrote: Anthony Towns wrote: The first paragraph of that section states: ``The package installation scripts should avoid producing output which it (sic) is unnecessary for the user to see and should rely on `dpkg' to stave off boredom on the part of a user installing many packages. [...]'' The fourth paragraph continues: ``If a package has a vitally important piece of information to pass to the user [...] it should display this in the `postinst' script and prompt the user to hit return to acknowledge the message.'' Well I'd never really read those two paragraphs side by side I must confess. Likewise. The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. Or 40 lines of garbage ralating to byte-compiling obscure emacs modules. Well, yes. Bytecompiling emacs modules: emacs19 emacs20 xemacs20 would be useful output, by comparison. To me, those sorts of outputs seem useful and helpful Some of them, a lot are massively useless debug output. Yeah, sure. It's the some that I'm interested in though. :) So, how about something like: Packages should briefly report the main tasks as they undertake them, in a similar manner to that used in init scripts, but should avoid producing unnecessary or overly verbose output. If a package has a vitally important piece of information to pass to the user [...same paragraph, moved up a bit] Packages should try to minimize the amount of prompting [...] ? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpgE8w8KGogI.pgp Description: PGP signature
Re: RFC: allow output from maintainer scripts
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Well, yes. Bytecompiling emacs modules: emacs19 emacs20 Anthony xemacs20 would be useful output, by comparison. How about something like this: Messages should only be displayed on the console if: - it represents a slow task, eg compiling modules (emacs) or compiling ls-R files (latex). Of course, this is a subjective criteria... What is a slow task? - it represents a task which could potentially crash the computer (not sure if any actually fall in this criteria???). - it represents a task that alters the state of the computer, eg starting a daemon, or changing a config file. Obviously, this could be debated... Any messages displayed should be brief, and a maximum of one line for each item. Any other messages probably should be done via debconf. Of course, this could do with some refinement, but I think you get the general idea. -- Brian May [EMAIL PROTECTED]
Re: RFC: allow output from maintainer scripts
On Wed, Oct 25, 2000 at 08:56:47AM +1100, Brian May wrote: Any other messages probably should be done via debconf. debconf isn't suitable for policy yet, apparently. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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
Re: RFC: allow output from maintainer scripts
Brian May wrote: How about something like this: Messages should only be displayed on the console if: - it represents a slow task, eg compiling modules (emacs) or compiling ls-R files (latex). Of course, this is a subjective criteria... What is a slow task? Policy explictly says you should NOT output things to stave off boredom on the part of a user. Displaying stuff for tasks that may be slow on my 386 clearly falls under that. - it represents a task which could potentially crash the computer (not sure if any actually fall in this criteria???). Yes, yes... - it represents a task that alters the state of the computer, eg starting a daemon, or changing a config file. Obviously, this could be debated... Nearly everything a postinst script does alters the state of the computer. -- see shy jo
Re: RFC: allow output from maintainer scripts
* Joey Hess [EMAIL PROTECTED] [001024 15:23]: Policy explictly says you should NOT output things to stave off boredom on the part of a user. Displaying stuff for tasks that may be slow on my 386 clearly falls under that. Hmm; I myself like twizzle sticks (ala fsck) to let one know the machine isn't spinning into oblivion... -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: RFC: allow output from maintainer scripts
Seth Arnold wrote: * Joey Hess [EMAIL PROTECTED] [001024 15:23]: Policy explictly says you should NOT output things to stave off boredom on the part of a user. Displaying stuff for tasks that may be slow on my 386 clearly falls under that. Hmm; I myself like twizzle sticks (ala fsck) to let one know the machine isn't spinning into oblivion... When someone needs to run fsck from their postinst, we'll talk. -- see shy jo
Re: RFC: allow output from maintainer scripts
On Tue, Oct 24, 2000 at 03:28:09PM -0700, Joey Hess wrote: Anthony Towns wrote: The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. Or 40 lines of garbage ralating to byte-compiling obscure emacs modules. Well, yes. Bytecompiling emacs modules: emacs19 emacs20 xemacs20 would be useful output, by comparison. Anything would be useful by comparison (and let's not even talk about the packages that spew tex output to the screen and what users think about that). But consider: one of these emacs packages is installing and it byte-compiles ok. Why should we display the message? Remember staving off boredom is not an answer. ``Policy shouldn't say packages should do such and such, because policy says packages shouldn't do such and such.'' isn't much of an argument. I think explaining what's happening so a user can diagnose what's meant to be happening if something hangs is useful, whether it's staving off someone's boredom or not. I still haven't seen any examples that seem genuinely worthwhile. If some can be came up with, this becomes something I might be able to agree with: Consider: Unpacking new netbase... Stoppiing portmapper: portmap. Unpacking new ssh... Stopping Secure Shell: ssh Unpacking new this... Unpacking new that... Installing ssh... Starting Secure Shell: ssh Installing netbase... Installing this... Installing that... . Consider trying to diagnose why users were complaining that ssh wasn't working for a while, even though it seems to have fixed itself now. Consider trying to work out how come portmap no longer seems to work, or even be available. 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. them, in a similar manner to that used in init scripts, but should avoid producing unnecessary or overly verbose output. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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
Re: RFC: allow output from maintainer scripts
Anthony Towns wrote: But consider: one of these emacs packages is installing and it byte-compiles ok. Why should we display the message? Remember staving off boredom is not an answer. ``Policy shouldn't say packages should do such and such, because policy says packages shouldn't do such and such.'' isn't much of an argument. Well I happen to agree with policy here. I think explaining what's happening so a user can diagnose what's meant to be happening if something hangs is useful, whether it's staving off someone's boredom or not. Consider: Unpacking new netbase... Stoppiing portmapper: portmap. Unpacking new ssh... Stopping Secure Shell: ssh Unpacking new this... Unpacking new that... Installing ssh... Starting Secure Shell: ssh Installing netbase... Installing this... Installing that... . Consider trying to diagnose why users were complaining that ssh wasn't working for a while, even though it seems to have fixed itself now. Consider trying to work out how come portmap no longer seems to work, or even be available. All right. This is useful, you've convinced me. 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. 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. -- see shy jo
Re: RFC: allow output from maintainer scripts
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. Jason
Re: RFC: allow output from maintainer scripts
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey I take your earlier point about a daemon maybe hanging as it Joey restarts, and perhaps a emacs byte-compile can hang Joey too. Heck, *anything* could conceivably hang. If that Joey happens though, there are tools like top and ps and strace Joey that are available to see if it has hung and help track down Joey what is hanging and why. Would it be possible (practical?) to print a message, only if it takes to long to start? eg: execute-or-print-message --timeout 60seconds --message Trying to start package... --command /etc/init.d/package start so, if for instance a daemon has a history of hanging, something can be done to make it easier to debug? -- Brian May [EMAIL PROTECTED]
RFC: allow output from maintainer scripts
Hello world, After some discussion on the debconf list [0] it appears that policy and current practice are in conflict, and that it's probably a good idea to get this conflict resolved before debconf gets added to policy. The conflict I'm referring to is from s2.3.8, Maintainer Scripts. The first paragraph of that section states: ``The package installation scripts should avoid producing output which it (sic) is unnecessary for the user to see and should rely on `dpkg' to stave off boredom on the part of a user installing many packages. [...]'' The fourth paragraph continues: ``If a package has a vitally important piece of information to pass to the user [...] it should display this in the `postinst' script and prompt the user to hit return to acknowledge the message.'' These two paragraphs are often put together to form the conclusion that: (a) You shouldn't have any non-crucial output from postinst (b) All output you do have must be followed by a Press enter prompt Hmmm. I'm not actually sure this conclusion makes sense now. Joey, am I mis-stating something? (It seems to me there's a difference between necessary output, which can be displayed, and vitally important output, which must pause the installation) The sorts of information which currently get displayed, but which don't get prompted for, are things like Restarting internet superserver: inetd, or Updating /etc/network/interfaces: succeeded. To me, those sorts of outputs seem useful and helpful, so I think policy should probably explicitly allow for them, or at least not forbid them as it apparently does atm. Some comments would be appreciated. Cheers, aj [0] [EMAIL PROTECTED] -- Anthony Towns [EMAIL PROTECTED] 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 pgpmVv6GPQOVD.pgp Description: PGP signature
