Re: dh_config_model_upgrade: package upgrade with Config::Model
On Friday 04 December 2009 11:18:46 Neil Williams wrote:
> The package version doesn't sound like a new project, who is using it
> (and why?).
Sorry, that's a typo. The version is 0.640-3. The project is new.
> (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 .
> 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.
> 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.
> Is it meant to just be one model per package or a unified model across
> all packages?
For now, it's one model per application that require a configuration. Package
without config must not use dh_config_model_upgrade
We can imagine to glue models together to provide system wide semantic
validation, (i.e. application A that must work with B is correctly configured
to work with B, and vice-versa), but we're not there yet.
> 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.
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] ?
If my mother-in-law sees this, I'm sure to get a phone call ;-)
This can of situation can be handled automatically.
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.
> > 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.
> 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 ?
> 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 ?
> It might be as simple as providing an empty shell script to replace
> dh_config_model *if* the system is sufficiently fault tolerant.
In this case, configuration files will simply be left as is. (which is also
the case if debconf variable libconfig-model-perl/automatic-upgrade is false)
> (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...
> > 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.
> > 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.
If the consensus is to remove this debconf question, I will.
> > (Simple instructions for CDBS should be provided. Help is welcome there)
>
> Provide a Makefile snippet that calls what you need, package that and
> allow packages to add it to the CDBS debian/rules.
ok. I'll dig this further.
> > 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. 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.
> > - 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.
> > - 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.
>
> > For more informations, see http://wiki.debian.org/PackageConfigUpgrade
>
> Which describes the technical minutiae of the codebase without
> explaining the "big picture" benefits of using the model or how the
> model proposes to "fix" the (IMHO non-existent) problem that it has
> invented.
Okay, I'll re-work the introduction part of this page.
> The commercial world is full of products that exist merely to fix a
> problem that the product designer has invented out of thin air. There
> are always some who will buy into such nonsense; I don't see Debian
> doing that. Please explain the problem you're trying to fix - I don't
> see it.
I hope I provided enough explanations.
All the best
Dominique
[1] http://config-model.wiki.sourceforge.net/
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
Reply to: