[pkg-lighttpd] Bug#498951: Bug#498951: closed by Olaf van der Spek <olaf at xwis.net> ()
Olaf van der Spek
olafvdspek at gmail.com
Sun Oct 24 20:46:22 UTC 2010
On Sun, Oct 24, 2010 at 9:44 PM, Jonas Smedegaard <dr at 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
> 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.
> 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? :-)
> 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.
> 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).
More information about the pkg-lighttpd-maintainers