Re: error setting ownership of symlink
In message "error setting ownership of symlink", email@example.com writes:
> On 27 Aug 1998, Dirk Luetjens wrote:
> > beta:# dpkg -i autoconf_2.12-9.deb
> > (Reading database ... 33581 files and directories currently installed.)
> > Unpacking autoconf (from autoconf_2.12-9.deb) ...
> > dpkg: error processing autoconf_2.12-9.deb (--install):
> > error setting ownership of symlink `usr/lib/autoconf/acconfig.h': No such file or directory
> > Segmentation fault
> > Any ideas?
> This seems to be common in the development kernels. Symlinks seem to be
> more strictly "enforced" than before (requiring a target to set
> ownership). Double-check that the target of the symlink actually exists.
> If it does, it should work ok, but if not, then dpkg will segfault. This
> is usually caused by dpkg not correctly ordering package installation
> under the newer kernels (dpkg needs some revision, fyi). If the target
> exists and it still segfaults, I guess repost and we'll take a better look
> at dpkg.
I have seen this several times as well; I am running development
kernels. I did a little bit of investigation. It turns out that this
happens when the symlink target does not yet exist. In every case that I
investigated, the target file was contained in the SAME package as the
symlink, but for some reason had not been installed yet. If you list the
package contents and find out what the symlink references, and do a
'touch' or 'mkdir' accordingly, then you can rerun dpkg and everything
There seem to be two separate problems here; first, files should be
unpacked before they are referenced, through any pathname. Second, even
if this doesn't happen properly, dpkg shouldn't segfault. I have been
meaning to look at the dpkg source code to see if I could figure out
what is going on here, but I haven't got around to it yet.
Ottawa Ontario Canada
firstname.lastname@example.org (remove everything after 'ca' to reply)