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

[Jonas Smedegaard]

On Mon, Oct 25, 2010 at 02:43:39PM +0200, Olaf van der Spek wrote:
>On Mon, Oct 25, 2010 at 12:30 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>>>> 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.
>>
>> You are not sure I want that, or?
>
>I think the user shouldn't be bothered with questions about whether a 
>module should be disabled.

So you find it more important to not "bother" our users with questions 
than to help provide idempotency of packages: allow packages to clean up 
after themselves.

You could ask at install time something like "Ignore module 
auto-disabling?", and (ah, another benefit of debconf!) mark the 
question as being of low severity to only bother users wanting to be 
bothered.

This would then need some option to lighty-mod-disable (e.g. --system or 
--if-ok) which packages should use, so as to distinguish automated 
requests from the sysadmin disabling a module.


>> Why do you keep talking about distribution freeze/release?  I am not 
>> (except in trying to clarify how I believe you are mixing things).
>
>I'm trying to tell you that the lighttpd.conf update might not be in 
>the next upload depending on whether that upload is targeted at 
>Squeeze.

Ah, I get it now.


>>>> 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?
>>
>> Because normal scripts require being invoked _after_ installation, 
>> whereas debconf preseeding is injected as "metaconfig hints" to the 
>> install process itself.
>
>Wouldn't it be better to add hooks for normal scripts to the install 
>process?

No.  You are right that it is possible, but debconf and package lists 
are the standard formats for the debian-installer, whereas hooks are 
custom code.

You dislike the amount of custom code needed to use debconf.  So do I.

I would like that to go away, and had (among other work) an hour-long 
phone international phone conversation with the author of Config::Model 
to encourage working on integrating those two.

For other parts of the Debian system I also want custom code to be 
avoided whenever possible.  I want to be able to remote-control the 
configuration of packages through the de-facto standard Debian system 
for that purpose: debconf.

You seem reluctant to this, and it seems to me that your reason for 
hesitating is exactly the same reason that I want you to do it: To avoid 
amount of custom code.  Your adding one distributed piece of custom code 
may help several others avoid custom pieces of code at install time.


>>> 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).
>>
>> How much actual experience do you have with Debconf?
>
>None, actually. As a developer.

Ah, that helps explain your scepticism.

Please do consider it - even though it needs custom code.

And feel free to ask if you need help finding good patterns. I believe 
the documentation is not that bad, actually, but if you have a concrete 
challenge I might be able to help dig out some other package solving a 
similar thing which you can look at for inspiration.

I could offer my help generally with maintaining it - but notice that 
you are a little team already.  Besides I favor other packaging tools 
(CDBS and git-buildpackage) which I imagine you wouldn't want to adopt 
just to get me involved.


  - 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/20101025/46818521/attachment.pgp>