Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Niko Tyni]

(dropped the debian-perl list, added the pkg-perl team)

On Wed, May 28, 2014 at 08:10:50AM +0200, Guillem Jover wrote:
> On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:

> > @debian-perl: To make this usable for the original problem (giving
> > dpkg-dev a working File::FcntlLock without a transitive hard dependency
> > on perlapi-*), I suppose the package should either be split or the
> > ${perl:Depends} dependency should be relaxed to a recommendation.
> 
> Either would work for me, the latter might be problematic for current
> code not assuming that it can fallback to use one of the pure perl
> versions though. Although checking now it seems only libdpkg-perl is
> making use of the module in Debian, so it might not be such an issue
> after all; and would avoid a round-trip over NEW, a very tiny package,
> and would guarantee the packages and modules are always present (even
> if not fully functional). Anyway, I'm fine with whatever you decide.

Hi, we've been looking at this again at the Debian Perl sprint in
Barcelona. Jens: see below for another feature request (and sorry
for bothering you again with this :)

> > (Hm, my preliminary testing indicates that 5.20.0 may introduce new
> >  challenges around PERL_DL_NONLAZY.  Urgh. Will investigate.)
> 
> Thanks, will take that into account! And I'm obviously interested in
> any results from that investigation, which might imply having to switch
> to always use the pure version for example. :)

We ended up moving XS modules into Perl version specific paths in 5.20, so
PERL_DL_NONLAZY=1 should no longer be needed, and the above "challenges"
became moot. Perl shouldn't be able to see binary incompatible modules
anymore.

However, this introduced another problem. As the architecture dependent
parts of @INC now vary with the Perl version, packages that put files
there also need a dependency on perlapi-* to ensure they match the
installed Perl version, otherwise they won't be found at all. See Perl
policy 4.4.2, at

 https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps

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?
In that case maybe something like File::FcntlLock::Any with a minimal
API would make sense?

For full disclosure, if we had the fallback we could setup the
modules something like this:

 /usr/share/perl5/File/FcntlLock.pm
    on normal arch-independent @INC; tries ::XS first and
    falls back to ::Pure from a special directory

 /usr/lib/<triplet>/libfile-fcntllock-perl/File/FcntllLock/Pure.pm
    in a special directory that only File::FcntlLock knows
    possibly with an additional symlink on the normal @INC too

 /usr/lib/<triplet>/<version>/File/FcntlLock/XS.pm (and .so)
    on normal arch-dependent @INC

The "special directory" part would be a Debian-specific deviation
that wouldn't need any upstream support.

This way we could honestly have the package just Recommend
perlapi-*, and have it still work (even if in a degraded state)
when there's version skew between Perl and the XS parts.

(Jens: I can have a shot at a patch for this if that helps...)
-- 
Niko Tyni   ntyni at debian.org