[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg broken? (fwd)



On Fri, 22 Jan 1999, Jason Gunthorpe wrote:

> I have heard of this serveral times in different contexts, some claim only
> a single file will not install, this guy says alot of them. Could someone
> perhaps investigate?

It's a known situation.  It has to do with a kernel bug that has since
been fixed upstream.  The lchown() call on i386's was pretty much
"swapped" for chown() in 2.1 kernels (and now 2.2) and thus worked the
same.  On the Alpha, it's a bit more complicated since we maintain DEC
Unix compatibility, so the calls could not be switched on the libc-level
at all.  To complicate things, calling lchown on older 2.0 kernels on the
Alpha returns the incorrect error code, thus making it even more
complicated.  As a result, compiling libc and dpkg (which is one of the
few packages that actually uses lchown explicitely if supported by the
kernel) with 2.0 kernels resulted in dpkg failure on 2.1 kernels, while
the converse was true for dpkg compiled for 2.1 kernels.

Because of all of this, a patch was generated for the kernel upstream as
well as a Debian patch for glibc to handle the proper (l)chown support
depending on the kernel being run.  The caveat was that the current kernel
had to return the proper error code if lchown() was called on older
kernels (which, prior to 2.0.35, it didn't).

My guess is, the person who is having the problem is probably using an
older RedHat kernel to boot and/or install Debian.  The RedHat disks
currently do not have the patched kernel on them (but will soon, from what
I hear), fyi.

For anyone having this problem, I do have a "temporary" dpkg tarball that
they can use that explicitly uses chown instead of lchown.  You can refer
them to ftp to beezer.med.miami.edu:/pub/chris/dpkg-chown

Also, if you get more users asking about this, you can easily refer them
to debian-alpha for more info and fix instructions.  If you decide to
handle the mail yourself, though, recommend either running a devel kernel
(well, now that 2.2 is finally coming out, that's an option) or running
2.0.36 or above as either of those kernels will return the correct error
code should the improper chown be called (thus allowing glibc to work its
magic and substitute properly).

C


Reply to: