On Fri, 4 Dec 2009 09:08:03 +0100
Dominique Dumont <dominique.dumont@hp.com> wrote:
> The last version of libconfig-model-perl (640-3) is now shipped with
> dh_config_model_upgrade.
The package version doesn't sound like a new project, who is using it
(and why?).
(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.)
Is this some kind of tasksel interface where the configuration is
modelled on a particular end-user implementation type (like desktop vs
server)?
Is this an upstream configuration attempt that is trying to work in a
downstream mode?
Is it meant to just be one model per package or a unified model across
all packages?
Just what is the point and what problem are you trying to solve?
> 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.
>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.
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".)
It might be as simple as providing an empty shell script to replace
dh_config_model *if* the system is sufficiently fault tolerant.
#!/bin/sh
exit 0
(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.)
> Let's assume that Joe, debian developer, wants to add smooth upgrade
> capability to his foobar package.
Why? What is the point?
> 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.
> (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.
> 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.
> - 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?
> - 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?
> 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.
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.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpWC3PB509aE.pgp
Description: PGP signature