dpkg problems. Am I alone?
Marc Singer writes:
>
> In looking at the latest sid, I'm finding that dpkg doesn't like to
> install some packages. It appears that all of the problem packages
> have symlinked files in the tar archives. The error is about dpkg
> being unable to set ownership of a symlink. Tar can extract the file
> fine, but dpkg stops installation of the package at this point.
>
> So, I want to know if this is known by anyone. I can look at it in a
> limited way since I'm not able to install compilers editors and the
> rest of the development tools.
Sorry for not having responded earlier, it looks like you have the
known lchown/chown problem. Starting from libc6.1 version 2.0.7u-4 (I
maybe wrong on the exact version), chown has been changed to follow
the POSIX semantic, and a new lchown replacement has been put.
There is two ways this can break your system:
1)
You must have a libc6.1 version greater than 2.0.7u-4 (the last one is
2.0.7u-5) and a dpkg greater than 1.4.0.31, most combinaisons that
includes an earlier version of one of these package will lead to a
non-working dpkg, you can solve the problem by extracting manually the
dpkg executable and libc6.1.so libraries from the deb with ar, and
replacing manually the one of your system.
It might also be important to have the most recent version of tar.
2) You must have a kernel 2.0.35+alpha-patches-2.0.35-0.2 from
gatekeeper, for previous 2.0 kernel versions, libc check at runtime to
see if the kernel implements a new syscall for lchown, but previous
kernels are not returning ENOSYS as expected.
I wonder, now that we have some experience on this issue, what about
releasing a new libc with chown an alias for lchown, there maybe a
non-neglectable number of people that do not upgrade regularly, and we
will be confronted for this problem for a long time. Making chown an
alias for lchown in libc does not break anything (as no program in
Debian use the POSIX chown semantics), and any version of any package
(dpkg, tar,...) should work without problems whether it uses chown or
lchown.
One the same subject, it might be better to check wether the new
lchown syscall is available in libc or not depending on the OS release
number than on the return value of the system call, there will
probably be some people that will use an old kernel version for some
reason.
These two changes looks worth to me, do you agree?
Loic
Reply to: