Le vendredi 4 décembre 2009 19:38:19, Neil Williams a écrit :
> That's a user change, I thought the point of this was that changes *not
> done by users* are causing problems. Different problem.
Currently, debian package will detect correctly if a user (or a script) left
the configuration unmodified and will upgrade the conf with the new file
coming from the package. This is perfectly fine.
As explained by gregoa, problem arise when a package script needs to keep
user's modifications and merge them with configuration data coming from new
packages.
Currently the only way to address this is to write ad-hoc code in the postinst
script. This is costly and often hard to maintain.
Another possibility is to perform three-way merge with ucf. This will often
succeed but not always: 3-way merge works at syntactic level and not semantic
level so it can often fails. For instance leaving duplicated config
parameters. and error prone.
Config::Model tries to fix this by performing the merge at semantic level.
> That's not how I understood the purposes of it, although it could be
> used that way, it isn't sufficient justification IMHO.
>
> If admins make changes, admins should expect to handle the dpkg
> conflicts.
This is where we disagree: admins are not the only users of Debian.
Config::Model tries to bring a solution for non-admin users. The kind of users
which are often comfortable on Ubuntu or Windows (yikes) because Ubuntu or
Windows tries to make thing easy for users (whether they succeed or not is
troll food and I will not express an opinion there :-p )
Config::Model tries to address 2 problems:
- configuration upgrade (which should be silent)
- application configuration (with the generated user interfaces)
I agree with you that experienced admins will not see a value in the GUI
("real men don't click") but the GUI will be welcome by casual users. IMHO,
Config::Model provides a way to generate these interfaces while no costing too
much to specify *and* maintain.
> I thought the idea of this was to handle changes not made by users - I
> think we agree that those instances are bugs.
To ease the user's life, Config::Model keeps users changes but also propagate
new data required by application evolutions.
> The postinst doesn't have to parse the conffile, it just has to not
> generate the dpkg result (by generating the conffile instead of
> packaging it) and allow the app to transition from one to the next.
This is not always the case. Hence some upgrade tools were written by Debian
(like ucf)
> If the existing file is different to what the package thinks it can
> upgrade, the package should not require dpkg to generate the error and
> the consequent halt of the package installation.
That a possibility which was choosen by RedHat. It's fine for servers, less so
for Desktops.
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
