On Sun, Oct 24, 2010 at 08:32:08PM +0200, Olaf van der Spek wrote:
On Sun, Oct 24, 2010 at 8:17 PM, Jonas Smedegaard <d...@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?
Hmm. Looking at it now again, and it is not warnings, just that current output is relatively verbose for scripting use.
Would be nice with a --no-verbose option which emits the module name (and noting else) when succesfully enabling. No surrounding info, nothing at all if already enabled, and just a silent errorcode if failing to enable.
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. :-)
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.
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. :-/
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.
I find it relevant to better support cleanup at removal, despite Windows providing a lousy UI for that particular task.
When removing the gcc package, the user suddently cannot use the gcc command, which she perhaps was depending on. What we can improve on is packages depending on packages, not (as is somewhat what Windows is trying, I believe) users (and other non-package routines) depending on packages. The local sysadmin needs to be knowledgeable about non-package package requirements.
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.
So what I envision is that e.g. sympa does 2 different things: * requests enabling of modules * declares modules required for it to workThose 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).
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.
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.
Ah, think I understand you now: Sort of the inverse of requiring too much custom code, tight? :-)
There's already an API for enabling/disabling most modules. What would Debconf add to that?
True, module enabling/disabling using the current API fulfills the original needs of this bugreport: packages needing certain module enabled.
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.
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.
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).
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.
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. ;)
He he - I guess I noticed that by now. ;-) - 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
