Re: Bug#149491: dpkg depends hard on working F_SETLK fcntl
Hi there. Just spent a whole 8 hours trying to work around this, and the
truth is this is *very* broken. To recapitulate and summary, we are
trying to do a debian install on a root directory mounted through nfs
from a remote server. This *should* work; however, because the client
has to run rpc.statd for f_setlk to work properly, and because dpkg
*requires* f_setlk to work, we are stuck in a no-win situation.
This took a lot of energy to realizing; I tried first to get a binary of
rpc.statd from another box to run on it, but then I got glibc skew
probelms and from there on it was just ugly. I ended up untarring a
virgin debian-3.0 root on the server, checking it with a chroot, and
finishing off the install on the client by doing some pretty intense apt
and dpkg fixing.
So I'd like to *repeat* the problem here by using Paul's argument:
> Some users may want to use an NFS server with broken locking
> when they don't have enough control over it to fix it.
>
> Reserving one directory name for the lockfile only would make
> that easy (a tiny local filesystem can be mounted there, a ramdisk
> for example), and it would leave dpkg essentially unchanged
> (just "/var/lib/dpkg/lock-dir/lock" or similar
> instead of "/var/lib/dpkg/lock").
This was CCed to a couple of lists a while back. Has there been no
discussion over it?
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
Reply to: