dpkg and lchown
Hi!
It's almost unbelieveable, but Darwin does not have the lchown()
function. dpkg detects this and uses chown() instead. That's
problematic for two reasons:
1) It changes the owner of the symlink's destination, which is not
what we want.
2) If the destination of the symlink doesn't exist, chown() will
fail, causing dpkg to abort the operation. This can happen when a
package contains symlinks that point at other symlinks - the sorting
done by dpkg-deb when creating packages doesn't help in this case. I
encountered this problem with gtk+.
The patch below (taken against the v1_9 branch) fixes that. When
lchown() is not supported, it doesn't try to set the owner of
symlinks at all.
-chrisp
Index: main/archives.c
===================================================================
RCS file: /cvs/dpkg/dpkg/main/archives.c,v
retrieving revision 1.28.4.3
diff -u -r1.28.4.3 archives.c
--- main/archives.c 2001/05/28 21:32:23 1.28.4.3
+++ main/archives.c 2001/07/26 14:42:53
@@ -547,12 +547,10 @@
debug(dbg_eachfiledetail,"tarobject SymbolicLink creating");
#ifdef HAVE_LCHOWN
if (lchown(fnamenewvb.buf,
-#else
- if (chown(fnamenewvb.buf,
-#endif
nifd->namenode->statoverride ?
nifd->namenode->statoverride->uid : ti->UserID,
nifd->namenode->statoverride ?
nifd->namenode->statoverride->gid : ti->GroupID))
ohshite(_("error setting ownership of symlink `%.255s'"),ti->Name);
+#endif
break;
case Directory:
/* We've already checked for an existing directory. */
@@ -608,10 +606,8 @@
ohshite(_("unable to make backup symlink for `%.255s'"),ti->Name);
#ifdef HAVE_LCHOWN
if (lchown(fnametmpvb.buf,stab.st_uid,stab.st_gid))
-#else
- if (chown(fnametmpvb.buf,stab.st_uid,stab.st_gid))
-#endif
ohshite(_("unable to chown backup symlink for `%.255s'"),ti->Name);
+#endif
} else {
debug(dbg_eachfiledetail,"tarobject nondirectory, `link' backup");
if (link(fnamevb.buf,fnametmpvb.buf))
--
chrisp a.k.a. Christoph Pfisterer "Any sufficiently advanced
cp@chrisp.de - http://chrisp.de bug is indistinguishable
PGP key & geek code available from a feature."
Reply to: