On Fri, Oct 17, 2014 at 12:37:27PM +0800, Thomas Goirand wrote: > On 10/17/2014 04:34 AM, Bas Wijnen wrote: > > So debconf needs to read configuration files, but it doesn't know how to > > parse them. So it does the only thing it can: it uses its cache. Which > > means that each and every package that uses debconf must make sure that > > they read the configuration files and update debconf's cache _before_ > > running debconf. And most of them don't do that. > > Could you name a few package for which this is the case? Has bugs been > opened for them?
I have not reported any bugs, because there is no solution that I consider acceptable yet. Any package with a config script that does not include db_set and that writes the result of db_get to a config file (in postinst) is broken. But, as I found, strictly speaking they are not always violating policy. Getting random packages from apt-cache rdepends debconf shows: - several packages that use debconf for questions that are only about actions that don't need to be (and aren't) stored in config files. - cxref uses ucf in postinst. This doesn't violate policy, but does (in case of local changes) give the wrong default in the debconf question, and an annoying "do you want to overwrite local changes?" after answering the question. If the default would have been correct, there would have been no need for that. - esmtp starts by asking if you want to overwrite your config and refuses to be configured by debconf if you don't. Also policy-compliant, but very unfriendly to users. - dict does it right. This costs it more than 20 lines of code in the config script. - dvi2ps does something I don't understand... It asks questions but never runs db_get. Presumably it pre-seeds some other package? - ibam depends on debconf but doesn't seem to ask any questions; it doesn't even have a config or postinst script. - gpm does it right, in surprisingly few lines. - grr does it wrong. This tiny investigation shows that most of the packages that handle configuration files are either doing it in a way that is not user-friendly, or that uses significant code in the config script. Both of those cases would benefit from taking that code out of the source (if it was there) and replacing it with an include statement. > > The above problems are solved by my plan to create a "static script > > library", which is included in config scripts at package build time. > > This library would define functions for parsing common config file > > formats, and can be included in config scripts with a line similar to > > ##DEBHELPER##. This has the benefit of solving the problem, without > > causing the problem of adding lots of duplicate code to the soures. > > Then such a library *must* be marked as essential, and installed by > default, otherwise it would break the install workflow. No; it's a _static_ library. It is included in the config script at package build time. This means every binary package using it will have a copy of the code in its maintainerscript. But the source packages do not. A change in the library requires a rebuild of all the packages for the change to take effect. That's not ideal, but better than marking it as essential, or making it part of debconf (which would also work, but requires Joey Hess to accept it, and so far he refuses to even acknowledge that there is a problem; even if he would, I find making it a separate package a more elegant solution). > > Oh yes, and I have some code ready for feedback. I haven't written the > > script libraries yet (and I want others to write some of them), but I > > have written the debhelper module for using them. I have set up a > > mini-dinstall repository where you can get the binary and source > > packages: > > deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main > > deb-src http://wijnen.dtdns.net/archive unstable main > > (Please ignore problems with the keys; I'm still getting it to work > > right.) > > > > The code is derived from dh-autoreconf and it is the first ever perl > > program I wrote. So please don't insult me, but also don't hold back > > when you see things that need to be improved. :-) > > Ok, you have a repository. But which package should we look into? Oops, sorry and thanks for the reminder. It's dh-parseconfig: http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig* > As for parsing files, I don't think using perl is a great idea. The perl script only pastes the file into the config script. The actual parsing is done by a script in the language that config is written in. That means there must be an implementation for every language (/bin/sh being the most important) and every common file type (ini and csv probably being the most important). Note that none of those parsing libraries have been written yet. I'll probably take some code from pioneers as a starting point. I intend most libraries to be included in the dh-parseconfig source, but it is set up in a way that allows other packages to add libraries as well. > Such configuration files sometimes may be huge. But anyway. I have a > list of features that such a library would need to do for .ini files. I don't have a bug tracker yet, but I can upload this to unstable if people don't complain too much about the code. ;-) Then the bts can be used for feature requests (and bugs of course). > This would include not only reading and writing to .ini files, but > also allow maintenance of them, like for example moving a directive > from one section to another (when this happens upstream). The library is meant to make common operations easy. If a package has special needs, it must still implement its parsing by itself. I think this is on the edge of useful enough for many and too specialist. Perhaps it would be possible to implement it not entirely in, but with help of the library. For example, if there are functions for "read value from section", "delete value from section" and "write value to section", it's only one if-statement (use value from new section if present, otherwise from old section; writing doesn't suffer because you wouldn't write to the old section anyway, you can just delete the old value). Thanks for you feedback, Bas
signature.asc
Description: Digital signature
