Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
[ CCed Jens and the Debian perl team for feedback on a proposal at
the bottom, leaving the rest for context. ]
On Tue, 2014-05-13 at 17:08:24 +0200, Gerfried Fuchs wrote:
> * Guillem Jover <email@example.com> [2012-06-17 19:46:50 CEST]:
> > On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:
> > > Package: dpkg-dev
> > > Version: 18.104.22.168
> > > Severity: normal
> > >
> > > dpkg-gencontrol makes annoying noise like this:
> > > dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
> > >
> > > Please silence it.
> > But you can silence it yourself, by installing libfile-fcntllock-perl,
> > or is that a problem?
> This also affects a cowbuilder chroot and ends up in its build logs.
> Either it is needed, then it should be a Depends, or not, then it
> shouldn't blabber about it and end up in build logs.
It is needed on NFS mounts, where the locks are going to be most needed,
as it's easier to get into a situation that several uncoordinate remote
systems are building the same thing in parallel, but those are also not
portably detectable. And unfortunately this is now a Recommends only
due to <http://bugs.debian.org/675947>, as it was causing issues when
introduceing new perl ABI versions.
> Yes, installing something in a pbuilder/cowbuilder chroot that isn't a
> Build-Depends (or Depends of the base system) is a problem in the sense
> that it somehow defeats the whole purpose of using a chroot for that in
> the first place. :)
Well, it's still just a warning, would people feel less pestered if it
was a simple info notice? I'd be fine with this immediate compromise
for 1.17.10, and can queue a patch for that right now.
Long term what I think would be best would be to get File::FcntlLock
into the perl core distribution, preferably upstream, but I'm not sure
how such proposals are handled there and if something like that would
be feasible, Jens what do you think? And/or would that be possible in
Debian, maybe in the interim or regardless of perl core upstream?
Otherwise, I guess I'll create a helper program in dpkg to be used by
the perl module, but that would be a slightly annoying last resort.