On Sun, Oct 24, 2010 at 10:46:22PM +0200, Olaf van der Spek wrote:
On Sun, Oct 24, 2010 at 9:44 PM, Jonas Smedegaard <d...@jones.dk> wrote:What warnings are we trying to avoid anyway?Hmm. Looking at it now again, and it is not warnings, just that current output is relatively verbose for scripting use.It's too verbose for normal use as well, I'll work on that.Would be nice with a --no-verbose option which emits the module name (and--quiet?noting else) when succesfully enabling. No surrounding info, nothing at all if already enabled, and just a silent errorcode if failing to enable.Why echo the module name?Sure, silencing is doable in postinst scripts, but just as you yourself find debconf too much custom code, I similarly would want to minimize here that will need replication across all packages wanting to enable modules. :-)What's the code complexity/size difference between --quiet and > /dev/null?
I would want my packages to emit during install the modules enabled.I can custom-code the silencing, custom-code parsing if enabled or skipped, and custom-code the emission.
I would prefer to simply feed to your script the list of modules I wanted enabled, and in return get a) a list of modules actualy enabled, and b) errorlevel 0. Or if failing then a) an error string explaining what went wrong and b) positive errorlevel of the kind of error.
I thought this was about dealing with conflicting modules.Ah: 1) I propose support for querying, with example use case. 2) You judge the example(!) as too complex compared to its usefulness. 3) I misunderstand you as judging the proposal. Sorry about that. :-/So what I would like was for packages that enable a module to be able to disable that module again on package removal iff no other packages(!) depend on that module being enabled.Hmm, I'm not sure.
You are not sure I want that, or?
Ah, ok. So you mean it is pending next packaging release. Cool!Eh, well, Squeeze is frozen, so I think it won't be in Squeeze.next packaging release: lighttpd 1.4.28-2(?) next distro release: debian 6.0 (codename Squeeze) Distro freeze is thus irrelevant for my remark, I believe.Not really. If a release is done that's supposed to go in Squeeze, this will probably not be a part of it.
Huh?Why do you keep talking about distribution freeze/release? I am not (except in trying to clarify how I believe you are mixing things).
Ah, think I understand you now: Sort of the inverse of requiring too much custom code, tight? :-)Eh, probably.
I meant to write "right", not "tight" :-P
Debconf interface would allow a subdistro (a.k.a. a Debian Pure Blend) or a large deployment to "remote-control" the install of lighttpd itself when it is not a package needing a module but some other use.Why are normal scripts not usable in that case?
Because normal scripts require being invoked _after_ installation, whereas debconf preseeding is injected as "metaconfig hints" to the install process itself.
One could argue that custom needs could simply execute custom code invoking the current API, but as little and simple the customizations the merrier - and when e.g. preparing an embedded device invoking code is more trouble than adding that related custom config snippets.Why?
Debconf is the config language of debian-installer, and thus the de-facto metaconfig language of the Debian distribution.
All sorts of other tricks are _possible_ to impose on an installed system, but only debocnf preseeding is channeled through the API of the official install routines.
I can provide debconf preseeding of an alian architecture without even having access to that hardware. I can also provide a script that the user of that installed system needs to invoke to apply my changes, but that is more complex and thus more error-prone and, well, clumsy.
User reconfiguration would also benefit from using the Debian-default dpkg-reconfigure interface rather than the package-specific API. Prime example here is the FreedomBox project of composing an embedded device to be user-friendly (i.e. only web interface, no need for CLI access), and here one approach considered is to work on improving the web UI for debconf (as alternative to writing yet another unique web-ui from scratch).That's an interesting case.Another related example (not modules, though) that I ran into just a moment ago: lighttpd by default use port 80 and fails during install if that port is already taken. If the port number could be preseeded, it would be possible for a Debian Pure Blend or a big deployment to install lighttpd using e.g. port 8080.Yeah, that failure isn't nice. But again I think Debconf is not the right way to do this kind of configuration, it requires (too much) custom code (I think).
How much actual experience do you have with Debconf? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
