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

Sun Oct 24 19:44:15 UTC 2010

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

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 work

Those 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
-------------- 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/b4c09df1/attachment.pgp>