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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
