[pkg-lighttpd] Bug#498951: Bug#498951: closed by Olaf van der Spek <olaf at xwis.net> ()

[Jonas Smedegaard]

On Sun, Oct 24, 2010 at 07:55:23PM +0200, Olaf van der Spek wrote:
>On Sun, Oct 24, 2010 at 5:58 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>>> I know, but lighttpd.postinst shouldn't enable any modules if this 
>>> isn't a fresh install, right?
>>
>> Ah, we were talking about different things, then.
>
>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.


>>>>  * Encourage package maintainers to first query then enable
>>>
>>> Why not an if not enabled flag?
>>
>> You tell me: Why not? ;-)
>
>Don't know.
>
>>
>> NB! Beware that negated questions is hostile: you effectively accuse 
>> your opponent of being against your proposal by default.  I am not.
>
>Sorry, didn't know.

I learned it myself only recently too.


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



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


>>>> Well, that too.  But the very thing of listing a bunch of modules 
>>>> commented out is a hint to the local admin (and the package 
>>>> maintainer!) that uncommenting is the preferred style of 
>>>> configuration here.
>>>
>>> ATM there's only rewrite that's commented out. No other modules.
>>
>> What are you talking about?
>
>Sorry, talking about SVN.

Ah, ok. So you mean it is pending next packaging release.  Cool!


>>>>  * Add debconf interface to declare space-delimited list of modules 
>>>>    to enable during install, by default installing only rewrite
>>>
>>> Debconf? I don't think that's necessary. And only usable at install 
>>> time.
>>
>> None of this is "necessary".  Debconf would be beneficial both for 
>> Debian Pure Blends and others wanting to to preseed a custom setup 
>> and for later sysadmin editing using dpkg-reconfigure.
>>
>> If you don't want your packaging to be nice in this area, then don't.
>
>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.

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.


  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-lighttpd-maintainers/attachments/20101024/2c59d74d/attachment.pgp>