tag 638291 + patch
thanks
On Sat, 20 Aug 2011, Sven Joachim wrote:
> It's not clear to me what the contents of the old version and the
> situation on the filesystem were, but this is reproducible even on fresh
> install. The reason is that conffile processing takes place after
> unpacking all non-conffiles, so for hardlinks to conffiles you hit the
> ENOENT bug. If a file is both a conffile and a hardlink in the package,
> it is treated as the latter.
The problem is that the hardlinking code is not aware that the target
file is still in .dpkg-new and not yet in its final location. This is
because conffile are not processed like normal files and thus do not
inherit the usual fnnf_deferred_rename flag.
The attached patch should tell dpkg to also use .dpkg-new for conffiles.
Not tested but it should be ok. Tell me if it works for you (not taking
the time to do it myself, since I'm in vacation).
Can you also turn your testcase in a patch against pkg-tests.git?
Thank you in advance.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
diff --git a/src/archives.c b/src/archives.c
index f060e70..442cdaf 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -764,7 +764,7 @@ tarobject(void *ctx, struct tar_entry *ti)
varbuf_add_char(&hardlinkfn, '/');
linknode = findnamenode(ti->linkname, 0);
varbuf_add_str(&hardlinkfn, namenodetouse(linknode, tc->pkg)->name);
- if (linknode->flags & fnnf_deferred_rename)
+ if (linknode->flags & (fnnf_deferred_rename|fnnf_new_conff))
varbuf_add_str(&hardlinkfn, DPKGNEWEXT);
varbuf_end_str(&hardlinkfn);
if (link(hardlinkfn.buf,fnamenewvb.buf))
