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

[Guillem Jover <guillem@debian.org>]

On Sun, 2014-05-18 at 14:38:31 +0200, Jens Thoms Toerring wrote:
> On Sun, May 18, 2014 at 06:04:45AM +0200, Guillem Jover wrote:
> > 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.
> 
> That went over my head;-) Is that something I should do (I'm
> also not sure how I could check within a module if some XS
> stuff is available).

Well, I think going for now with the pure perl version would solve
our immediate problem, we could go over the rest separately. I just
mentioned it now because it would avoid dropping an then having to
reintroduce the XS code again.

> Perhaps it would be simpler in the long run to include the
> file locking stuff directly into the libdpkg-perl package
> itself, e.g. as a Dpkg::Lock sub-module. Since I'm sure I
> don't understand properly what the real problem is (sorry,
> I've never taken a good look at the way how Debian manages
> packages, that has always been white magic to me;-) I can't
> decide what the correct way to go would be. It could be pos-
> sible to 
> 
> a) add File::FcntlLock in XS form directly as Dpkg::Lock (or
>    a simplified version since obviously only locks on whole
>    files are required)
> b) add the pure Perl version
> c) add a version that is modified so that it determines the lay-
>    out of the C flock struct somewhere in a BEGIN block by com-
>    piling and running a C program and then using its output (as
>    I can see libdpkg-perl requires the availability of a C com-
>    piler). I'd write that for you if you like.
> 
> I don't think that this would require a lot of extra mainainance:
> I didn't had to change anything about File::FcntlLock within the
> last three years and the last serious bug was fixes about 5 years
> ago.

Because the File::FcntlLock module is generally useful, I'd rather see
it improved, instead of forking a local copy for dpkg-dev alone. I don't
think option c) would solve the issue I described, though.

I think the conventional way of doing what I was proposing might be:

 * Create a File::FcntlLock::XS module that loads the XS code,
   which would only contain C_fcntl_lock.
 * Either create another module, say File::FcntlLock::Perl or ::Pure
   or similar name with the pure perl implementation, or embed the pure
   perl code in the File::FcntlLock module at build time. The former
   would in addition get rid of your CPAN upload concerns, as you could
   ship the .pm module normally.
 * In File::FcntlLock decide which implementation to use depending on
   File::FcntlLock::XS being available or not through an evaled require.
 * Then in Debian the File::FcntlLock::XS and corresponding .so file
   could be split into a different package.

Hope that clarifies.

Thanks,
Guillem