On Mon, Jun 06, 2016 at 11:44:00PM +0200, Guillem Jover wrote: > On Sun, 2016-06-05 at 14:37:51 -0700, Josh Triplett wrote: > > Control: tags -1 + patch > > > > The attached patch implements the change I suggested, dropping fcntl > > locking in favor of flock, and documenting that change in the changelog > > along with the rationale. > > > >From 0c6eddc8200e7bea482ad65c5870f7977847d26a Mon Sep 17 00:00:00 2001 > > From: Josh Triplett <j...@joshtriplett.org> > > Date: Sun, 5 Jun 2016 14:27:38 -0700 > > Subject: [PATCH] Always use flock for file locking; drop Recommends on > > libfile-fcntllock-perl > > > > Per the flock(2) manpage, NFS clients going back to Linux 2.6.12 > > translate flock into an fcntl lock on the entire file. > > This is a non-portable Linux-only assumption. dpkg works on other > systems besides Linux-based ones.
I'm aware; however, the question is whether other NFS client implementations fail to implement flock, and whether dpkg supports doing parallel builds on those systems on their less capable NFS implementations. What other NFS client implementations does dpkg support, and what do those other clients do with flock? It's unfortunate that the failure mode for flock on NFS is "silently no-op" rather than "fail"; the latter would make it easier to fall back to a serial build, for instance. Is there any reliable, portable way to detect an NFS filesystem with non-functional locking, or more generally a filesystem with non-functional locking? > I'm also unhappy even about the > fallback to flock when fcntl is not available, as on other systems > the locks might not see each other so that's the worst possible > behavior. Another potential solution to the problem would be to avoid serializing this at all, which then avoids the need to lock. What if each run of the requisite tool generated a different target control file, for instance? Or perhaps debian/files should become debian/files.d? As long as the corresponding dpkg tools support reading that format when constructing a .deb, migrating to that for parallel builds seems reasonable. That might also speed up dpkg-gencontrol, which at the moment can be a major bottleneck in the parallel build of a multi-binary package. > I've in fact been looking into this recently. And I'll ping the perl > maintainers to try to get the required packaging fixes implemented in > libfile-fcntllock-file done. Otherwise I'll probably embed something > similar to that module as a private Dpkg module. Great to hear; thank you. - Josh Triplett
