On Tue, Nov 26, 2013 at 09:44:40PM -0400, Joey Hess wrote: > Bas Wijnen wrote: > > Currently, many packages only do 2 > > (Citation needed.) http://codesearch.debian.net/search?q=db_get+path%3A.*config%24 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 defaults. 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 debconf). 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. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature