Bug#827074: libfile-fcntllock-perl: Please implement File::Fcntllock::Any

[Dominic Hargreaves]

Package: libfile-fcntllock-perl
Version: 0.22-3
Severity: normal

Control: tags -1 upstream
X-Debbugs-Cc: ntyni at 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...)