Hi,
Here is the result of a blind rebase of the conffiledb patches sent a
while ago, rebased against dpkg master. Untested. I'll include a few
thoughts with each message. Probably I have terribly mutilated the
patches; please feel free to let me know of any infelicities and I'll
be glad to inco
From: Sean Finney
Date: Sun, 11 Oct 2009 12:43:50 +0200
A small number of functions from help.c are required for outside-of-dpkg
functioning of the conffiledb routines. As we want to be able to have
functional unit tests as well as to use these routines in other cmdline
programs (such as a hypoth
From: Sean Finney
Date: Mon, 14 Dec 2009 08:27:32 +0100
(Note: this information is largely duplicative of the doxygen documentation
comments, found in conffiledb.c and conffiledb.h)
The files conffiledb.{c,h} define a set of routines for adding and removing
stored versions of "pristine" conffile
From: Sean Finney
Date: Mon, 14 Dec 2009 08:27:33 +0100
dpkg now ships with a directory (/var/lib/dpkg/conffiles) for holding the
dist versions of packaged conffiles and other conffiledb meta-information.
Signed-off-by: Jonathan Nieder
---
Simple, sensible.
debian/dpkg.dirs |1 +
1 files
From: Sean Finney
Date: Mon, 14 Dec 2009 08:27:34 +0100
In tarobject() (src/archives.c), some sleight of hand is performed with
the backend pipe of the struct tarcontext to intercept conffiles and
place a copy in the available conffile database for the package before
extracting it as usual.
In d
From: Sean Finney
Date: Mon, 14 Dec 2009 08:27:35 +0100
A new option is presented to the user in the conffile resolution prompt,
offering to show the diff between the previous dist version of the conffile
and the new dist version of the conffile. This can be useful for the local
admin to know wha
Hiya,
Once again, everything prefixed with IIRC and it may no longer
be the case.
On Fri, May 06, 2011 at 02:49:30AM -0500, Jonathan Nieder wrote:
> debug is now part of libdpkg so I left that one out.
>
> help.c describes itself as "help.c - various helper routines", which
> doesn't seem so far
From: Sean Finney
Date: Mon, 14 Dec 2009 08:27:36 +0100
The conflict resolution prompt has been updated with a new option for
automatic merging:
M : attempt to automatically merge the differences
This functions by performing a 3-way diff using the new conffile, the
currently-insta
Hi!
On Fri, 2011-05-06 at 02:42:17 -0500, Jonathan Nieder wrote:
> Here is the result of a blind rebase of the conffiledb patches sent a
> while ago, rebased against dpkg master. Untested. I'll include a few
> thoughts with each message. Probably I have terribly mutilated the
> patches; please
From: Sean Finney
Date: Mon, 14 Dec 2009 08:27:37 +0100
When a merge is successful, store the common ancestor of the merge (the
pristine version of the conffile from the previous package version) in
a special location. While this may not have an immediate benefit, it poses
the oppurtunity for fur
sean finney wrote:
> Basically, it's a pain to try and use anythign from help.c because of
> the numerous intertwined static/global/extern variables involved.
> for example if you wanted to link against it in a unit test i think
> there were a couple dozen local static variables and possibly other
Guillem Jover wrote:
> Thanks for picking this up again! Some time ago I started a rework of
> the series, but didn't finish it up. I've pushed a branch now [0] with
> those changes, rebased against master, but take into account they only
> build and not even cleanly, they should be considered ext
Hi!
On Mon, 2011-04-25 at 09:47:47 +0200, A Mennucc wrote:
> Il 25/04/2011 07:28, Guillem Jover ha scritto:
> > But my main problem right now is that I didn't find clear
> > documentation of the “debdelta” file format, the closest thing that I
> > found was the debpatch [1] example file in the de
On Fri, May 06, 2011 at 02:59:52AM -0500, Jonathan Nieder wrote:
> Ah, memories. The main piece to revisit might be what sort of
> identifier to use for in these modern days of multiarch. I also
I think pkg:arch would suffice instead of pkg, right?
> think there was some talk about atomic rena
On Fri, May 06, 2011 at 03:11:30AM -0500, Jonathan Nieder wrote:
> It might make sense to consider the patches up to here as something
> to polish and make mergeable to start out. It would already be useful.
Agreed :)
> What happens if the previously configured version was installed before
> con
On Fri, May 06, 2011 at 03:24:47AM -0500, Jonathan Nieder wrote:
> Ah, now the memories come back! I find the "While this may not have an
> immediate benefit" mentioned above convincing. I am not happy about
> storing extra data that does not seem very relevant, just in case.
The idea IIRC was t
On Fri, May 06, 2011 at 03:19:09AM -0500, Jonathan Nieder wrote:
> Is "diff3 -m" the state of the art for this? Well, it will do to
> start. In the long term maybe some people will want to use some other
> tool to perform the merge, like RCS "merge" or something Config::Model
> based.
I think a
On Fri, May 06, 2011 at 10:24:20AM +0200, Guillem Jover wrote:
> Thanks for picking this up again! Some time ago I started a rework of
> the series, but didn't finish it up. I've pushed a branch now [0] with
> those changes, rebased against master, but take into account they only
> build and not ev
sean finney wrote:
> I think pkg:arch would suffice instead of pkg, right?
Yes, probably. I'm not sure whether arch:all packages are currently
tied to a specific arch.
> Yeah, I think previous versions of the patch series had "new", "old",
> "tmp", "cur" or similarly named directories, and vari
sean finney wrote:
> Yeah I don't think we got to the point where we were considering
> issues like that. I'd guess that the menu should be made more flexible
> so that if the required conffiledb data isn't there for any reason that
> it falls back to the old behavior/options.
Yep, agreed. A he
sean finney wrote:
> On Fri, May 06, 2011 at 03:19:09AM -0500, Jonathan Nieder wrote:
>> In the general case, the right merge result may depend on the content
>> of other files (for example, if the user renamed a file so the new
>> pristine version should be renamed, too). Luckily I don't think t
sean finney wrote:
> The idea IIRC was that if a merge is likely to have conflicts, having the
> common ancestor of the merge would provide the ability to offer the
> post-merge diffs of the previous merge (to the on disk version as well
> as the old pristine version) could provide further options
22 matches
Mail list logo
