Quoting Christian Perrier <[EMAIL PROTECTED]>: > > > Well .. if notes are going away, that's something entirely different. > > > > I looked at the .config file in question, and I have three notes. > > > > I have a warning message that is marked as high, a message that tells the > user > > how to actually build the package, which is medium, and I check for the > > presence of another essential package and display a warning if it is > missing. > > qmail-src/build could either be considered important enough to have > its priority raised to high...or could maybe move to README.Debian. > > Considering that users who install qmail-src probably already know > that they will have to do something special to get the qmail binary, > I'd probably suggest moving that one to README.Debian > > The same probably goes for the qmail-src/warning for about the same > reasons. > > qmail-src/ucspitcp could be considered an "error" and thus use the > "error" template type. Such "error" templates are recommended to be > used in situation where a previous check verifies whether some > conditions are fulfilled or not. > > > > > > The reason it was coded that way, was that I read this in the packaging > manual > > at http://www.debian.org/doc/packaging-manuals/debconf_specification.html: > > > > "note This template is a note that can be displayed to the user. As > opposed to > > text, it is something important, that the user really should see. If it is > not > > possible to display it, it might be saved to a log file or mailbox for them > to > > see later." > > In the discussion that lead to the mass bug filing, Joey Hess > mentioned that this has been abandoned (at least partly....IIRC > debconf only mails "critical" notes, or so...better ask Joey directly. > > > This tells me that note is exactly what I want to use to display info to > the > > user. This is the entire reason I implemented debconf in the first place, > was > > to display messages to the users. If that is not going to be possible > anymore, > > I will have to switch back to dumping the messages to the console. > > > > If I don't include the message that you have to take an additional step to > > actually build a binary qmail package, most users won't figure it out, > don't > > know where the readme files, and will simply get frustrated and either > complain > > about it or file a bug. > > Well, your package description is saying: "Source only package > for building qmail binary package"..... > > From my POV, it makes very clear that installing this package will > *not* give you a working qmail but you'll have to do some other > actions to have it running properly (namely compile it). > > It is my understanding that users who will install this package will > be some kind of power users...at least powered enough to go looking in > /usr/share/doc/qmail-src > > > I could change the type to text, which will have no effect on the end users > > experience, but would remove the evil note. I just need to force the user > to > > see the message, and click OK. I don't really care if it's a note, text, > > whatever. I just need them to see it, and acknowledge it. That's all. > > > "error" type could be considered appropriate as an alternative to > README.Debian even if we're not exactly speaking about an "error" > > > I can't promise that noone will criticize this later, > though....probably with the rationale that wanting to display this > information in all cases could be considered as too strong. > > >
Unfortunately, you're giving the users far too much credit. I have had to deal with bug reports for issues far more trivial than that. I do, however, run into some bright people every now and then. I'll just go ahead and just remove all the debconf prompts all-together, I'm sick of having to argue about it. If people get pissed off about it, I will direct them to you. Expect a new qmail-src shortly. Will that end this once and for all? Jon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
