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 <d...@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
signature.asc
Description: Digital signature
