[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

--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





More information about the pkg-lighttpd-maintainers mailing list