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

Sun Oct 24 22:30:31 UTC 2010

On Sun, Oct 24, 2010 at 10:46:22PM +0200, Olaf van der Spek wrote:
>On Sun, Oct 24, 2010 at 9:44 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>>> 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.
>
>It's too verbose for normal use as well, I'll work on that.
>
>> Would be nice with a --no-verbose option which emits the module name 
>> (and
>
>--quiet?
>
>> noting else) when succesfully enabling.  No surrounding info, nothing 
>> at all if already enabled, and just a silent errorcode if failing to 
>> enable.
>
>Why echo the module name?
>
>> 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. :-)
>
>What's the code complexity/size difference between --quiet and > 
>/dev/null?

I would want my packages to emit during install the modules enabled.

I can custom-code the silencing, custom-code parsing if enabled or 
skipped, and custom-code the emission.

I would prefer to simply feed to your script the list of modules I 
wanted enabled, and in return get a) a list of modules actualy enabled, 
and b) errorlevel 0.  Or if failing then a) an error string explaining 
what went wrong and b) positive errorlevel of the kind of error.

>>> 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. :-/
>>
>> 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?

>>>> 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.
>
>Not really. If a release is done that's supposed to go in Squeeze,
>this will probably not be a part of it.

Huh?

Why do you keep talking about distribution freeze/release?  I am not 
(except in trying to clarify how I believe you are mixing things).

>> Ah, think I understand you now: Sort of the inverse of requiring too 
>> much custom code, tight? :-)
>
>Eh, probably.

I meant to write "right", not "tight" :-P

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

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

Debconf is the config language of debian-installer, and thus the 
de-facto metaconfig language of the Debian distribution.

All sorts of other tricks are _possible_ to impose on an installed 
system, but only debocnf preseeding is channeled through the API of the 
official install routines.

I can provide debconf preseeding of an alian architecture without even 
having access to that hardware.  I can also provide a script that the 
user of that installed system needs to invoke to apply my changes, but 
that is more complex and thus more error-prone and, well, clumsy.

>> 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).
>
>That's an interesting case.
>
>> 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.
>
>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?

  - 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/4f1c231a/attachment-0001.pgp>