Re: Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
- To: Jens Thoms Toerring <email@example.com>
- Cc: Niko Tyni <firstname.lastname@example.org>, email@example.com, Gerfried Fuchs <firstname.lastname@example.org>, Julien Cristau <email@example.com>, firstname.lastname@example.org
- Subject: Re: Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
- From: Guillem Jover <email@example.com>
- Date: Sun, 18 May 2014 06:04:45 +0200
- Message-id: <20140518040445.GA8351@gaara.hadrons.org>
- Mail-followup-to: Guillem Jover <firstname.lastname@example.org>, Jens Thoms Toerring <email@example.com>, Niko Tyni <firstname.lastname@example.org>, email@example.com, Gerfried Fuchs <firstname.lastname@example.org>, Julien Cristau <email@example.com>, firstname.lastname@example.org
- In-reply-to: <20140517233912.GA25865@toerring.de>
- References: <20140516090535.GA2934@toerring.de> <20140516155425.GA26395@gaara.hadrons.org> <20140516200617.GA682@estella.local.invalid> <20140517233912.GA25865@toerring.de>
On Sun, 2014-05-18 at 01:39:12 +0200, Jens Thoms Toerring wrote:
> On Fri, May 16, 2014 at 11:06:17PM +0300, Niko Tyni wrote:
> > Would it be possible to probe for the contents of the flock struct with C
> > code at build time, and then use that information to write out a pure perl
> > module that regenerates the structs at run time (probably with pack())?
> > It would still be architecture dependent (and thus go in
> > vendorarch/sitearch) but it wouldn't need a rebuild across Perl upgrades.
> I've got it to work and send atttach the new version - it's now
> a pure Perl module, created when running 'perl Makefile.PL'.
> Please let me know if this helps to solve the problem. If it
> does I'll upload it to CPAN.
Wow nice! Yes I think this would solve the issue. But I've got a slight
concern about this new approach and binary compatibility, though. The
inferred information used at build time is disconnected from the actual
function being used at run-time. This could fail or stop working if for
example, a new fcntl(3) versioned symbol was introduced that used a
different ABI (unlikely), or more probably new fcntl commands got
introduced to handle say a layout change in its struct flock, change in
member size, alignment or similar, and then perl core switched to use
that new symbol or the module kept using the old commands. We already
have seen this at least for the fcntl(2) to fcntl64(2) syscall
transition on GNU/Linux for example, which also switched userland to
transparently use F_SETLK64, F_SETLKW64 commands and friends to be able
to use the new struct flock64 and fcntl64 syscall.
What about, preserving the XS module, and make the code try to load it
and if not available, fall back to the new pure perl code? I think that
would palliate such concern.
In Debian libdpkg-perl could switch back to a strong Depends, and the
libfile-fcntllock-perl could Recommend a new -xs variant for example?