Control: reassign -1 libdpkg-perl Control: forcemerge 677865 -1 On Sun, 2016-10-30 at 09:16:10 +0100, Adam Borowski wrote: > Package: dpkg-dev > Version: 1.18.10 > Severity: minor
> Since forever, dpkg-gencontrol spams us with dangerously-looking warning: > dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is > not NFS-safe > > However, "man 2 flock" says: > # In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e., > # the scope of locks was limited to the local system). Instead, one could > # use fcntl(2) byte-range locking, which does work over NFS, given a > # sufficiently recent version of Linux and a server which supports locking. > # Since Linux 2.6.12, NFS clients support flock() locks by emulating them as > # byte-range locks on the entire file. This means that fcntl(2) and flock() > # locks do interact with one another over NFS. Since Linux 2.6.37, the > # kernel supports a compatibility mode that allows flock() locks (and also > # fcntl(2) byte region locks) to be treated as local; see the discussion of > # the local_lock option in nfs(5). > > Kernel 2.6.11 is prehistory (literally: not in git); stretch will use 4.10 > and absolutely requires at least 3.2, jessie ships 3.16 and requires 2.6.32, > to get a Debian system which will even boot on 2.6.11 you'd need to get way > into archive.d.o. Systems that old can't even unpack modern packages, and > backporting dpkg there would be a quite hard task. The code is in perl, and this is true for Linux, but this is not a portable assumption. In any case yes I'm aware this is annoying, and we have been trying to solve this in multiple ways, the last one was trying to get libfile-fcntllock-perl so that it could be safely depended by libdpkg-perl, but at this point the plan in #677865 seems overally more enticing. So I'm going to go with that. Thanks, Guillem
