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

[Guillem Jover]

Hi!

On Sun, 2015-05-24 at 20:11:42 +0300, Niko Tyni wrote:
> 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...)

I've been looking recently at creating a small helper to delegate the
locking to, because the automatic dbgsym packages and dpkg coloring
have exacerbated this annoyance when building packages :), but that
poses varios problems, and using an XS module is definitely the
cleanest approach. And the mail from Josh just reminded me that this
seems to have fallen through the cracks. :)

As I've mentioned before I'd really prefer to use the pre-existing
module to avoid duplicating work, but if the correct solution might
take too much effort, I might look into embedding something based on
this module into dpkg itself temporarily.

Also maybe we should file the above as a bug report against
libfile-fcntllock-perl and block this one aginst the new one?

Thanks,
Guillem