[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hi!

On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:
> On Tue, May 27, 2014 at 04:49:35PM +0200, Jens Thoms Toerring wrote:
> > Let's hope the new 0.20 version on CPAN is the final one;-)
> 
> Thanks for your awesome work, Jens!

Absolutely, the same goes for the debian-perl team! :)

> @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.

> This way dpkg-dev could still depend on the package, and either fall
> back to File::FcntlLock::Pure if File::FcntlLock::XS doesn't work, or
> just unconditionally use File::FcntlLock::Pure. Not sure which is cleaner.

As I've mentioned before I think always using one of the pure versions
could potentially lead to ABI issues, so I'd rather only use as a
fallback when the XS is not available or functional if possible. And I'll
be implementing that for dpkg 1.17.10, leaving the dependency metadata
until the packaging side has been decided on your side.

> In the fallback option, dpkg-dev should probably set PERL_DL_NONLAZY=1
> before trying to load File::FcntlLock::XS. See #479711. 

> (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. :)

Thanks,
Guillem


Reply to: