On Fri, 4 Dec 2009 17:10:20 +0100
Dominique Dumont <dominique.dumont@hp.com> wrote:
> On Friday 04 December 2009 11:18:46 Neil Williams wrote:
> > (FYI the upstream CPAN description doesn't answer any of my
> > questions below either. At no point is a Config Model explained or
> > described or is any attempt made to explain *why* either the
> > maintainer or the user would want this in use.)
>
> Fair enough. I've updated the introduction of Config::Model wiki on
> SourceForge. [1] I hope that this will convince you of the value of
> Config::Model .
It could do with some level of examples of just what kind of packages
are sensible candidates. Packages like exim4 and postfix are too
complex for some external parser to create a new interface and the kind
of changes needed are always beyond casual users. OTOH minor packages
shouldn't need this kind of support in the first place - it's a bug in
the package.
> > Is this some kind of tasksel interface where the configuration is
> > modelled on a particular end-user implementation type (like desktop
> > vs server)?
>
> There's no relation to apt tasksel.
Then why it is a model not yet-another-parser?
It should be Config::Buggy::Parser
i.e. a parser for buggy configs that upstream can't be bothered to fix
properly.
> > Is this an upstream configuration attempt that is trying to work in
> > a downstream mode?
>
> Err... Assuming I understand your question, this is an upstream
> project that tries to help downstream packagers.
No, I meant why is this an upstream package that is trying to do the
job that packages themselves should do themselves and which Debian
(downstream) has to fix when those packages get it wrong.
> > Just what is the point and what problem are you trying to solve?
>
> The main goal is to lower the cost (in terms of time) of providing
> configuration tools to end user. So that developers (or packagers)
> will be able to afford the creation and maintenance of more graphical
> configuration tools (with wizard, integrated help ...).
>
> If we can manage that, I think that most casual users (i.e. non-geek)
> will be grateful.
Better to fix the packages themselves to have more intelligent config
file handling internally - *without* adding another dependency.
*IF* the package already needs perl, *maybe* it could use this. Adding
it to packages that do not currently need perl is unwarranted,
especially when perl interferes with package installation.
> Another goal is to avoid casual users seeing things like this:
>
> Configuration file `/etc/sensors3.conf'
> ==> File on system created by you or by a script.
> ==> File also in package provided by package maintainer.
> What would you like to do about it ? Your options are:
> Y or I : install the package maintainer's version
> N or O : keep your currently-installed version
> D : show the differences between the versions
> Z : background this process to examine the situation
> The default action is to keep your current version.
> *** sensors3.conf (Y/I/N/O/D/Z) [default=N] ?
That is a bug in the package, as described in my other reply. If the
user hasn't changed that file, the package should be able to cope with
the changes without prompting. Whichever package caused the file to be
modified in such a way that it cannot be upgraded cleanly is BUGGY.
Trying to fix that bug by adding perl *as a runtime dependency* (or
worse, as a pre-depends) to a non-perl package is just not helpful. Do
what you like with perl at build time, I care about not adding perl to
runtime situations that haven't needed it before.
(Don't get me wrong, I like perl and I use it a lot.)
> Using config-model could also help in reducing the number of lline of
> openssh- server postinst script (480 lines) by removing the code
> dedicated to upgrades.
but then adding an entire dependency. :-(
> > > The aim of dh_config_model_upgrade is to provide an easy way for a
> > > debian developer to add better configuration upgrade to the
> > > packages they maintain.
> >
> > I read the announcement and the wiki page and I still don't
> > understand the aim of the project - you describe the problem but I
> > don't see how Config::Model solves anything and the existing
> > "descriptions" don't actually explain what the Model is or why it
> > would be useful.
>
> I hope [1] will help in explaining the goal.
Only slightly. I still don't see a real use for it.
> > From an embedded perspective, we certainly don't want every
> > configurable package depending on perl at package installation /
> > upgrade time - that's why we have cdebconf.
>
> Embedded world has other constraint. Does the user often store
> configuration data in embedded device ?
Yes. Think iPAQ. Specific changes are often needed
in /etc/fstab, /etc/inittab and other areas - the rest just need to
upgrade cleanly.
What would be better with embedded stuff is a way to never allow these
dpkg conflicts to arise, or failing that some way to just assume 'Y'.
> > This is especially important for packages with Priority higher than
> > optional. If any of those packages start to use this, *I* am going
> > to be the one who has to patch it out of them, so I need to know
> > how to replace your code with a static configuration (created by
> > the root filesystem management scripts) *and* disable the postinsts
> > such that they can run without perl. ("Essential" has no meaning in
> > embedded Debian - you might only have a reconfigured busybox,
> > uclibc, a kernel and {a rebuilt} cdebconf as what Debian currently
> > means by "Essential".)
>
> dh_config_model is currently involved only with configuration
> upgrades.
>
> It could also be used to generate at build time a generic
> configuration file. But that's not the case right now. Would that
> help you ?
No, because it's perl. It needs to be without perl - i.e. within the
package and using the support within the package.
> > (In essence, your models *must* support not being implemented at all
> > - bog standard, default configuration just as you get when telling
> > debconf never to ask any questions. This is how packages are
> > installed as build dependencies on the buildd's. For embedded
> > purposes, the packages must also support exactly this config
> > without /usr/bin/perl existing at all.)
>
> I'm still not clear on how configuration data is handled in embedded
> devices...
1. Customised installation / root filesystem creation tools create
specialised configuration files for this specific type of device at
installation.
2. Package updates must not break these configurations *or* halt the
package upgrade process.
Other than that, it's normal conffile handling.
(Some embedded systems do have perl, it's just that perl cannot be
assumed to exist.)
> > > Let's assume that Joe, debian developer, wants to add smooth
> > > upgrade capability to his foobar package.
> >
> > Why? What is the point?
>
> Avoid asking users configuration questions during packages upgrades.
> This could make dist-upgrades between Debian releases easier.
No, it hides the problem inside another dependency. The package should
handle it's own config files *and* the bugs that result.
If that package is already perl, maybe an extra perl module isn't a big
deal. When that package is not perl and is a Priority: important or
higher, it will be a problem.
> > > The end user may have to answer a medium debconf question asking
> > > him whether to upgrade foobar package with Config::Model.
> > > Hopefully, that's all the end user will see.
> >
> > How is that any more understandable than upgrade foobar package with
> > max_wait ? It is *less* relevant to the specific package, it makes
> > no sense and encourages a "who knows? just click yes to get rid of
> > it" response so common in Windows land.
>
> This question has a 'yes' default value. Currently, config-model is
> experimental, and this provides the user a way to skip upgrade with
> config- model is something goes wrong.
That doesn't answer my question. Encouraging blind clicks to 'yes' isn't
helpful.
> > > This requires to:
> > > - add a dependency on libconfig-model-perl in foobar control file
> >
> > For a package that does not currently use perl, that is an
> > unwarranted change.
>
> That's depend on how painful is the configuration upgrade for user.
No, it is unwarranted. Fixing the wrong bug.
> For instance, if you have saved cups config file through the web
> interface, you can no longer upgrade cupsd without answering a ucf
> question. That's not cool.
That's a bug in the cups package and the web interface, no need to
require perl. It's bad enough with defoma (which is to be going away at
some point).
> > > - add or update foobar.config file so that the question is raised
> > > by debconf. This file is generated from config-config-model
> > > delivered by libconfig-model-perl package
> >
> > How is that to be translated?
>
> In libconfig-model-perl package.
How is that to be package-specific and actually make sense to the user?
> > > - add or update foobar.postinst file so that the configuration is
> > > upgraded if the user answered yes to the question above This
> > > file is generated from postinst-config-model delivered by
> > > libconfig-model-perl package
> >
> > Why hand this task to a module when the maintainer is responsible
> > for it working and might as well do it in the postinst with direct
> > control over exactly what questions are asked and how they are
> > translated?
>
> Less code to maintain. But that's the maintainer choice whether to
> control it directly or use a tool set.
I still think this is being over-played and has a very low usefulness
count compared to actually fixing the packages directly.
By the time the package needs Config::Model it's already too late, the
bug has occurred. Hence Config::Bug::Parser.
There shouldn't be a need for any 'model' if the package isn't buggy.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgp472lGF1kr_.pgp
Description: PGP signature