[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 18:32:08 UTC 2010

On Sun, Oct 24, 2010 at 8:17 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>> So my question is, where do I enable the default mods?
> You can use a common packaging pattern, or invent your own custom approach.
> I know only of common packaging patterns involving debconf, which you don't
> want to use as I understand it.

I don't remember saying that. I thought Debconf was mostly for asking
questions. By default I don't mean what the user would like to enable,
I mean what the package would enable without asking the user.

> I find your suggestion (of a not-enabled flag) a good idea.  Better than my
> suggestion. :-)

What warnings are we trying to avoid anyway?

>>>>> This would also make it possible for packages to disable conflicting
>>>>> modules, which involves checking if exists and enabled, ask for permission
>>>>> to disable (as it might be needed by other setup snippets!) and fail the
>>>>> package install if not being granted permission.
>>>> That sounds too complex.
>>> Too complex for what? for being possible, of priority to you, relevant to
>>> other package maintainers, or something else?
>> Useful in general. Mods are usually enabled with a good reason.
>> Providing a warning might be helpful.
> I suspect you only take _some_ situations into account.
> Example: Without a mechanism to disable modules, packages are unable to
> fully (yet reliably!) clean up after themselves when removed.

I thought this was about dealing with conflicting modules.
Asking for permission to disable a module on uninstall sounds a lot
like the Windows questions where it says a DLL is 'probably' unused
and asks you to remove it.

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

>> The 'idea' of Debconf is quite nice, but it doesn't seem general enough
>> and I think it requires too much custom code.
> I agree that debconf requires custom code.
> Not sure what you mean by not being "general enough", though.

Well, Debconf generally only allows a subset of package configuration
to be done.
There's already an API for enabling/disabling most modules. What would
Debconf add to that?

> I am involved in Debian Pure Blends (heck, I coined that very term!) and
> would really really appreciate it being supported here, to help encouraging
> more widespread use of lighttd (not only apache2).
> Your opinion counts here, however, as you are the one burdened with
> maintaining whatever is added to the packaging.

Well, I'm always open to improvements. Don't let my tendency to
discuss and question things stop you. ;)



More information about the pkg-lighttpd-maintainers mailing list