First of all, I want to ask for a reconsideration of the decision not to fix this bug. The thing is that in some cases, the NFS client isn't entirely under the user's control, which means that the existing workaround doesn't work. I provide a solution for that below, but I think it is a good idea nontheless to implement the "ignore locking" option for such cases.
My particular case is that I want to build a new filesystem image for my Yopy PDA. The Yopy already runs Linux, but I prefer a "real" Debian system. :-) So I need it to bootstrap, and I want it to do that over NFS. I haven't succeeded so far in getting the locking to work, and I don't really feel like putting much effort it in, because I'm not even going to use that system once the bootstrapping works. So I ask, for cases like this one, please reconsider. Anyway, I did manage to get a working setup without working nfs locking, and I want to mention it here so people who see this bug report know how to proceed even without a good NFS client. What you do is mount the nfs disk, and mount a loopback system on it. Inside that loopback system, locking will work, and dpkg doesn't complain. The only problem is that you cannot work directly on the nfs server's disk, but for bootstrapping that will usually not be a problem. I'm not sure if there are other reasons for running dpkg over nfs anyway. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
