Guy Hulbert writes:
> On Thu, 2009-17-09 at 14:11 +0200, Dominique Dumont wrote:
>> 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.
>
> This email looks very familiar. Did you send something quite simi
On Thu, 2009-17-09 at 14:11 +0200, Dominique Dumont wrote:
> 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.
This email looks very familiar. Did you send something quite similar a
few months ago?
I see
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 modi
Stefano Zacchiroli writes:
> ... now it is only the two of us which needs to stop talking and start
> proposing patches as needed :-)
Before patches, I've created a page on Debian wiki to better articulate the
proposal:
http://wiki.debian.org/PackageConfigUpgrade
I'll update this page regularl
Stefano Zacchiroli writes:
> ... now it is only the two of us which needs to stop talking and start
> proposing patches as needed :-)
ok. Here's the plan:
- Identify a "candidate" package to add (as a patch) an upgrade
feature based on Config::Model.
- Then, I'll patch this source package to
Harald Braumann writes:
>> Agreed. But VCS solution is a 80% success/20% silent
>> failure. Config::Model is a 80% success/20% abort. The latter should
>> be easier to deal with for average user.
>
> But you don't need to silently merge (and thus silently fail in some
> cases). You can still ask
On Thu, Feb 26 2009, Harald Braumann wrote:
>
> But there are 3 possible situations here:
> 1. value has been changed between the last and the new maintainer
> version
> 2. value was modified locally
> 3. both of the above
Well, a complete analysis of the situations ucf faces are at [0]
On Fri, 27 Feb 2009 13:35:56 +0100
Dominique Dumont wrote:
> Stefano Zacchiroli writes:
> > But then we are back at the issue of a 80-20 problem, and I see the
> > VCS solution as more flexible and more readily available.
>
> Agreed. But VCS solution is a 80% success/20% silent
> failure. Confi
On Fri, Feb 27, 2009 at 01:35:56PM +0100, Dominique Dumont wrote:
> I think your numbers are right. The main problem I see is that the
> automatic merge will not be able to inform the user whether the
> merge is correct or not. In case of merge failure, the application
> will exit on error and leav
Stefano Zacchiroli writes:
> I can agree, at least in theory. But as we all known, due to how
> source code tends to work, in 90% of the cases automatic merges do the
> right thing. Well, of course I cannot prove that number, but my
> personal feelings is that with a "high confidence" automatic me
On Thu, Feb 26, 2009 at 07:07:30PM +0100, sean finney wrote:
> On Thu, Feb 26, 2009 at 09:14:23AM +0100, Stefano Zacchiroli wrote:
> > Well, it depends on how dpkg currently handles merges. My impression
> > (as a user, never looked at the actual code) is that it not even tries
> > to merge, it sim
hiya zack,
On Thu, Feb 26, 2009 at 09:14:23AM +0100, Stefano Zacchiroli wrote:
> Well, it depends on how dpkg currently handles merges. My impression
> (as a user, never looked at the actual code) is that it not even tries
> to merge, it simply discovers that the local file is not pristine and
> t
Harald Braumann writes:
>> I fail to see the differences (no pun intented) between "the last
>> version I've merged" and the current file ...
>
> I mean the last maintainer version I merged into the installed version,
> not the result of the last merge.
ok
> But there are 3 possible situations
On Thu, Feb 26, 2009 at 01:25:33PM +0100, Dominique Dumont wrote:
> > Also, there is of course no guaranteed that no conflicting changes
> > lead to a configuration file semantically sound,
> That's the main problem I see with VCS like merge. The main problem is
> that the merge result *should* be
Manoj Srivastava writes:
> /etc/kernel-pkg.conf, for example, is in Perl. You may define
> functions, variables, closures (given enough make-kpkg-fu) and have it
> all work.
Agreed. But this is valid for power user that would not really need
the safe merge capability provided by Config::Model
Manoj Srivastava writes:
> Well. If the maintainer so desires, ucf does have this to say:
> ,[ Manual page ucf(1) ]
> | --three-way
[ ... ]
> Seems like this is what is desired; however, the reason this is
> not on by default is that some configuration files can be huge, an
Stefano Zacchiroli writes:
> Well, it depends on how dpkg currently handles merges. My impression
> (as a user, never looked at the actual code) is that it not even tries
> to merge, it simply discovers that the local file is not pristine and
> then asks the user. On the contrary, every VCS I'm aw
On Wed, Feb 25, 2009 at 06:03:03PM +0100, Dominique Dumont wrote:
> Stefano Zacchiroli 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 m
On Wed, 25 Feb 2009 12:08:00 -0600
Manoj Srivastava wrote:
> Well. If the maintainer so desires, ucf does have this to say:
> ,[ Manual page ucf(1) ]
> | --three-way
I thought I remembered seeing smth. like this.
> Seems like this is what is desired;
Yes, this is exactl
On Wed, 25 Feb 2009 17:32:08 +0100
Dominique Dumont wrote:
> Harald Braumann 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
On Wed, Feb 25 2009, Dominique Dumont wrote:
> Manoj Srivastava writes:
>
>> (I generally tend to code configuration files in a scripting
>> language if the code is written in a scripting language).
>
> Uh ?
/etc/kernel-pkg.conf, for example, is in Perl. You may define
functions, vari
On Wed, Feb 25 2009, Dominique Dumont wrote:
> Harald Braumann 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 bet
Manoj Srivastava 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 create
Stefano Zacchiroli 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 poi
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
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 merg
Harald Braumann 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 mod
On Wed, 25 Feb 2009 09:28:52 +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
Jonas Smedegaard 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 su
-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 b
[ 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
31 matches
Mail list logo
