FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-25-2009, 07:28 AM
Dominique Dumont
 
Default Proposal to improve package configuration upgrades

[ this discussion was started on debian-perl. I'm restarting it on
debian-devel following Gregor Hermann suggestion ]

Hello

The other day, I was upgrading cups and dpkg did ask me the usual way
if I wanted to keep my cups config file or take the upstream version.

Like always, I asked for a diff and was quite puzzled because I did
not remember anything about editing this file. Then I remembered that
I did a modification through cups admin web interface.

Previous common story you might say. But for a casual user (like my
mother-in-law which now use Debian Lenny ;-) ), this can be
frustrating:
- I did modify the config through a nice web interface
- during the upgrade, I either have to look at all the gory details of
the config file or I have to loose my configuration.

So I was thinking that this is a typical case where the upgrade could
be smoothly handled by Config::Model.

Either in automatic mode where user data and upstream modifications
are merged (*) or in manual mode where the graphical (or curses)
interface is fired up so the user can check what's going on.

Of course, there's no miracle. For the merge to work automatically and
the result to be valid, the semantic of the configuration file must be
known by Config::Model. This is done by describing the structure and
constraints of the configuration file in a model (hence the
Config::Model name).

What do you think about this ?

All the best

(*) If you want I can go more in details on how an upgrade can be done

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 09:35 AM
Jonas Smedegaard
 
Default Proposal to improve package configuration upgrades

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Feb 25, 2009 at 09:28:52AM +0100, Dominique Dumont wrote:

>Of course, there's no miracle. For the merge to work automatically and
>the result to be valid, the semantic of the configuration file must be
>known by Config::Model. This is done by describing the structure and
>constraints of the configuration file in a model (hence the
>Config::Model name).

Do Config::Model support migration from one model to another?

Example: CUPS 2.x has boolean option foo, which is changed in CUPS 3.x
to numeric option foobar.


- Jonas

P.S. Please cc me on responses, I am not subscribed to -devel

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmlHtcACgkQn7DbMsAkQLjcSACfSHHm6+wMFV anffFsDWr9brsl
1gkAoJRQWvyvmGEuRxA7aC3iqhkHfIsc
=V7EK
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 10:05 AM
Dominique Dumont
 
Default Proposal to improve package configuration upgrades

Jonas Smedegaard <dr@jones.dk> writes:

> Do Config::Model support migration from one model to another?

Yes. In fact model version n can include specific attribute to deal
with migration from n-1 to n.

> Example: CUPS 2.x has boolean option foo, which is changed in CUPS 3.x
> to numeric option foobar.

In such a case, CUPS3.x model would need to speficy that:
- boolean option foo is status deprecated (which means the value can
be managed, but the option foo is hidden from the user in the
interfaces)
- the default value of foobar can be computed from foo value (using
compute attribute of Value object. See [1] for gory details)

More complex value migration scenarios are possible.

All the best

[1] http://search.cpan.org/dist/Config-Model/lib/Config/Model/ValueComputer.pm

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 03:15 PM
Harald Braumann
 
Default Proposal to improve package configuration upgrades

On Wed, 25 Feb 2009 09:28:52 +0100
Dominique Dumont <dominique.dumont@hp.com> wrote:

> Of course, there's no miracle. For the merge to work automatically and
> the result to be valid, the semantic of the configuration file must be
> known by Config::Model. This is done by describing the structure and
> constraints of the configuration file in a model (hence the
> Config::Model name).
>
> What do you think about this ?

I don't really know Config::Model. But the main problem I have with the
current system is, that I only see diffs between the currently
installed version and the new package version.

No what I really would like to see is the diff between the last version
I've merged and the new package version. So changes can easily be seen
(changes in defaults, new/removed parameters or just white-space
changes?) and merging would work without a conflict in most cases.
Similar to like SCMs work.

Config::Model could be useful in addition, but would it support such a
work-flow?

Cheers,
harry
 
Old 02-25-2009, 03:32 PM
Dominique Dumont
 
Default Proposal to improve package configuration upgrades

Harald Braumann <harry@unheit.net> writes:

> I don't really know Config::Model. But the main problem I have with the
> current system is, that I only see diffs between the currently
> installed version and the new package version.

With ucf, you see a diff between current file (i.e. installed version
with your modifications) and the new package version.

> No what I really would like to see is the diff between the last version
> I've merged and the new package version.

I fail to see the differences (no pun intented) between "the last
version I've merged" and the current file ...

> So changes can easily be seen (changes in defaults, new/removed
> parameters or just white-space changes?) and merging would work
> without a conflict in most cases.

With Config::Model:
- you would not see white space or any other formatting difference
- your customized values would be merged into the new package file
(more accurately, loaded in Config::Model configuration tree using
the new package *model*). Thus you would see the delta between your
new file and the new default value. See this example of a screenshot
[1] where the config values different from "default" are shown with
a green arrow
- yes, merging would work mostly without conflict

> Similar to like SCMs work.

The main difference between a SCM and Config::Model is that a SCM
works purely at text level without knowledge of the semantic of the
file under control. OTOH, Config::Model uses the semantic knowledge
provided by the model to perform the upgrade.

> Config::Model could be useful in addition, but would it support such a
> work-flow?

Provided I've understood correctly your work-flow, I'd say mostly yes...

All the best

[1] http://freshmeat.net/screenshots/69123/74589/

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 03:49 PM
Stefano Zacchiroli
 
Default Proposal to improve package configuration upgrades

On Wed, Feb 25, 2009 at 05:15:52PM +0100, Harald Braumann wrote:
> No what I really would like to see is the diff between the last version
> I've merged and the new package version. So changes can easily be seen
> (changes in defaults, new/removed parameters or just white-space
> changes?) and merging would work without a conflict in most cases.
> Similar to like SCMs work.

Actually, this is something I've been pondering about for a
while. Having /etc under some VCS (as many of us, I presume, already
have by the means of etckeeper and similar tools), diff file merging
can be seriously improved.

The point is that we of course do not want neither to add the
dependency on some VCS into dpkg, nor to have dpkg making the choice
of which VCS.

So, it looks like that what we need is a pluggable mechanism into
dpkg, which dpkg will invoke when configuration file change conflicts
are encountered. A usual /etc/*.d/ place where to stick some script
with a well-defined API or something like that ...

Would something like that be thinkable of or am I totally on crack?

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c' ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu tous ceux que j'aime
 
Old 02-25-2009, 04:00 PM
Manoj Srivastava
 
Default Proposal to improve package configuration upgrades

On Wed, Feb 25 2009, Dominique Dumont wrote:


> So I was thinking that this is a typical case where the upgrade could
> be smoothly handled by Config::Model.

> Of course, there's no miracle. For the merge to work automatically and
> the result to be valid, the semantic of the configuration file must be
> known by Config::Model. This is done by describing the structure and
> constraints of the configuration file in a model (hence the
> Config::Model name).

Do we have an idea of how many configuration files can be
described in terms of such a model? (I generally tend to code
configuration files in a scripting language if the code is written in a
scripting language).

While I suspect a large number of our configuration files are
simple, I fear that a significan chunk of them are fairly complex; and
possibly not amenable to being described in terms of a non-trivial
model.

manoj
--
Drop the vase and it will become a Ming of the past. The Adventurer
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 04:03 PM
Dominique Dumont
 
Default Proposal to improve package configuration upgrades

Stefano Zacchiroli <zack@debian.org> writes:
> Actually, this is something I've been pondering about for a
> while. Having /etc under some VCS (as many of us, I presume, already
> have by the means of etckeeper and similar tools), diff file merging
> can be seriously improved.

I tend to disagree.

>From a user point of view, you will get the same diff output whether a
SCM performs the diff or ucf performs the diff.

So your proposal will probably not help my mother-in-law to upgrade
the packages on her system ;-)

For seasoned sys admin, storing /etc/ files under a SCM will give a
much better roll-back capability if a config is screwed up by a manual
merge.

All the best

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 04:45 PM
Dominique Dumont
 
Default Proposal to improve package configuration upgrades

Manoj Srivastava <srivasta@debian.org> writes:

> Do we have an idea of how many configuration files can be
> described in terms of such a model?

I do not know how many. I'd say most of the files that do not use
variables. For instance exim config is out. I do not know for Apache
config files.

So far, I've created models for OpenSsh [1] (quite easy) and Xorg [2]
(more challenging and the model is still not complete)

You will be able to try yourself OpenSsh editor as soon as
libconfig-model-openssh-perl is accepted by ftp-masters.

> (I generally tend to code configuration files in a scripting
> language if the code is written in a scripting language).

Uh ?

> While I suspect a large number of our configuration files are
> simple, I fear that a significan chunk of them are fairly complex; and
> possibly not amenable to being described in terms of a non-trivial
> model.

Agreed. We may need to use hybrid solution for the most complex
configuration files. Something like exim-like template + Config::Model
for the template variables.

All the best

[1] http://cpansearch.perl.org/src/DDUMONT/Config-Model-OpenSsh-1.203/lib/Config/Model/models/
[2] http://cpansearch.perl.org/src/DDUMONT/Config-Model-Xorg-0.513/lib/Config/Model/models/

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-25-2009, 05:08 PM
Manoj Srivastava
 
Default Proposal to improve package configuration upgrades

On Wed, Feb 25 2009, Dominique Dumont wrote:

> Harald Braumann <harry@unheit.net> writes:
>
>> I don't really know Config::Model. But the main problem I have with the
>> current system is, that I only see diffs between the currently
>> installed version and the new package version.
>
> With ucf, you see a diff between current file (i.e. installed version
> with your modifications) and the new package version.
>
>> No what I really would like to see is the diff between the last version
>> I've merged and the new package version.
>
> I fail to see the differences (no pun intented) between "the last
> version I've merged" and the current file ...

Well. If the maintainer so desires, ucf does have this to say:
,----[ Manual page ucf(1) ]
| --three-way
| This turns on the option, during installation, for the user to
| be offered a chance to see a merge of the changes between old
| maintainer version and the new maintainer version into the
| local copy of the configuration file. If the user likes what
| they see, they can ask to have these changes merged in. This
| allows one to get new upstream changes merged in even while
| retaining local modifications to the configuration file. This
| is accomplished by taking the configuration file and stashing
| it in a cache area during registration, and using diff3 during
| the install (the stashed file name is a munged version of the
| full path of the configuration file to avoid name space
| clashes). Note This option appeared in Version 0.8 of ucf,
| which was the first version released into unstable and
| ultimately Sarge. The version of ucf in woody does not contain
| this option.
`----


Seems like this is what is desired; however, the reason this is
not on by default is that some configuration files can be huge, and ucf
did not want to stash away _all_ the configuration files handled by it
into /var. The exectation was that most developers with smallish
configuration files would use --three-way, but that expectation was
unfounded.

manoj
--
In the stairway of life, you'd best take the elevator.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 05:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org