On Tue, Oct 26, 2010 at 02:37:59PM +0200, Olaf van der Spek wrote:
On Mon, Oct 25, 2010 at 3:41 PM, Jonas Smedegaard <d...@jones.dk> wrote: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.AFAIK idempotency isn't the right word.
Oh, ok. What I meant was for a Debian system to be exactly in the same state before and after installing+removing+purging e.g. sympa.
Yes, in this case I think it's better to not bother the user than to do perfect cleanup.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.That doesn't solve anything, a normal user wouldn't see the question.
It solves the issue of your package collecting cruft of other packages' install routines because they cannot revert during purge: Normal users would not see the question, while providing an opt-in for careful users.
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."lighty-enable-mod ..." seems to be the minimal amount of code/data. A Debconf approach wouldn't use less data, would it?
Above is an introduction. Doesn't make sense to discuss that out of its context below.
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.Haven't heard of Config::Model before. I'll have a look.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.I understand, but IMO that may/should involve improving Debconf if necessary.
Sure. Improvements won't hurt.And while waiting for improvements to debconf to occur, the larger packaging ecosystem will benefit from adding custom debconf code, I believe.
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 andEh, what team? :p
The package lists 3 uploaders.
git-buildpackage) which I imagine you wouldn't want to adopt just to get me involved.Why would a change be necessary before you can get involved?
Instead of debating that, let's try the opposite:Would you be interested in teaming up with me in maintaining lighttpd for Debian?
Due to my personal streamlining (I am involved in 140+ packages), I require all packages that I am involved in to use CDBS and git-buildpackage.
I am happy to educate you in using those tools. But don't expect to convince me to use SVN or dh (a.k.a. short-form debhelper - I happily use debhelper, but wrapped with CDBS instead of letting it take over the whole rules file).
Is that of any interest? - 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
