On Sun, Oct 24, 2010 at 9:44 PM, Jonas Smedegaard <[email protected]> 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 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. > So what I envision is that e.g. sympa does 2 different things: > > * requests enabling of modules > * declares modules required for it to work > > Those two might be equal, but some features might be optional and thus > skipped if not available (here I am not talking about concrete mechanisms in > lighttpd but similar tricks with Apache2). That sounds reasonable. Using server.module would be the ideal way IMO, except that it doesn't support duplicates. >>> 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. > Ah, think I understand you now: Sort of the inverse of requiring too much > custom code, tight? :-) Eh, probably. > 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? > 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? > 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). Olaf -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
