Package: libfile-fcntllock-perl Version: 0.22-3 Severity: normal Control: tags -1 upstream X-Debbugs-Cc: nt...@debian.org
In #677865 a long discussion took place about how to avoid the warning about NFS locking in the absence of libfile-fcntllock-perl. The issue (briefly) is that libdpkg-perl needs to use File::Fcnttlock for locking over NFS, but can't depend on it, because that would hamper bootstrapping a new major version of perl. Niko's 2015 proposal at [1] still seems to be the preferred one, but there was no response from upstream, so I am filing this as a new bug report in case it can be implemented for Debian (and forwarded upstream, obviously). In fact, I'm going to file it as two separate bugs, reflecting the upstream-relevant and Debian-relevant parts. Niko, I hope you don't mind me refactoring your words in this way. Quoting: > To achieve the goal of having a libfile-fcntllock-perl package which > doesn't have a hard dependency on perlapi-*, we need another place to > put File::FcntlLock::Pure, which is architecture dependent but not > Perl version dependent. That could be something like > /usr/lib/<triplet>/libfile-fcntllock-perl > However, I'd like to punt information about that solely to the > libfile-fcntllock-perl package, so that callers wouldn't need > to be aware of the details. > > Jens: would it be possible to have the main File::FcntlLock module > fall back to ::Pure (or even ::Inline after that, I suppose) in case > ::XS is not found on @INC? Or are the API differences mentioned > in the documentation big enough that this wouldn't really work? The documentation implies that the API is identical, and it looks that way to me too from the documentation. > In that case maybe something like File::FcntlLock::Any with a minimal > API would make sense? Still, I think implementing File::FcntlLock::Any would be the cleanest/ least risky way forward, and given the niche requirement, doesn't really have any downsides. > (Jens: I can have a shot at a patch for this if that helps...)
