[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debconf as a registry

On Tue, Nov 26, 2013 at 09:44:40PM -0400, Joey Hess wrote:
> Bas Wijnen wrote:
> > Currently, many packages only do 2
> (Citation needed.)


On Tue, Nov 26, 2013 at 06:16:19PM -0800, Russ Allbery wrote:
> > Currently, many packages only do 2, and that is wrong.
> And those packages are all buggy, and whenever you encounter one, please
> do file a bug and get that package fixed.  I've fixed this bug in various
> packages over time, including some of my own.

Yes, I want those bugs fixed too.  That's my reason for starting this
thread.  But I don't want it fixed in a way that creates new problems.
Filing bugs is a good idea, but I'm pretty sure it falls in the category
"please discuss this on -devel first".  For such a mass bugfiling, I
don't want "please copy this nontrivial code into your script" as part
of the solution.

> I agree with Joey that a package's own maintainer scripts should be
> responsible for parsing the package's configuration files.

Certainly.  You seem to have misunderstood my intention.  I don't mean
to say we should force packages to use a standard package.config.  That
file should be used to do all the things it must do.  What I'm proposing
is to make it easy for packages with simple file formats (the majority
of cases) to do what they should to: read their config and using it as

Being responsible is not the same as doing it alone.  In this case, help
would be useful.  And due to the limits of when it is run, there aren't
many places it can come from (either an Essential:yes package or

But while the debhelper-addon-trick seems ugly to me, it does have
several advantages:
- It is nonintrusive; only packages which want to use it do.
- It works; the config files will contain copies of the required code.
- There is no code duplication in the source packages.  (Lots of it in
  the binary packages, of course; this is like using a static library.)

It's the best solution I can currently think of.  Would you agree that
this would be useful?

I was thinking of one format, which is key-value pairs on a line each.
There are 3 options for the separator: '\s*=\s*', '=' and '\s+'.  Also,
the value may be enclosed in quotes.

To make it really nice, it could support ini headers.

And of course, this method doesn't suffer from "even packages that don't
use it get burdened by this", so more complex formats such as xml-based
things could also be supported.

> There are too many possible cases that will come up over time, such as
> a need to migrate one value to another, and the package should be an
> expert in its own configuration syntax.

If there is anything that doesn't fit the implemented format(s), there
is of course no requirement to use this.  It is simply a tool to make
doing it Right easier.  For migrating values, I think it would still be
useful to first read them in, though, so I don't think that's a good
example of this.


Attachment: signature.asc
Description: Digital signature

Reply to: