Hi,
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).
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.
Best regards, Jens
--
\ Jens Thoms Toerring ________ j...@toerring.de
\_______________________________ http://toerring.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
