Turns out the problem was that I was building with make 3.81, which doesn't support the trailing "=" syntax in "define VAR =" (and for some reason silently ignores the whole block?). Just deleting that one = sign makes everything work for me. Would it be okay to remove that and maintain 3.81 compatibility just a little longer?
BTW, as far as the strange "debian/tmp/debian/tmp" path, my workaround has nothing to do with the dh_install step that was failing on those paths, so I believe the path is fishy but unrelated to this particular issue. David On Sat, Dec 3, 2016 at 6:17 PM David Barnett <[email protected]> wrote: > I did notice the apparent duplication in the path, but I'm not seeing any > evidence that any commands in a define'd variables like that get executed, > e.g. if I change them to "echo blah", "/bin/false", or a bunch of > non-syntactically-valid gibberish. > > David > > On Fri, Dec 2, 2016 at 7:28 PM James McCoy <[email protected]> wrote: > > That implies that $(DESTDIR) is being set to debian/tmp/debian/tmp. > $(DESTDIR) is set by the line: > > install-stamp-indep: DESTDIR=$(CURDIR)/debian/tmp > > so is $(CURDIR) somehow debian/tmp when install-stamp-indep is run? > > > The issue here seems to be that the munge-man-directories helper in > debian/ > > rules is not getting invoked, those directory moves are skipped, and > there is > > no man/ru/ directory at the expected path (only man/ru.UTF-8/ and > man/ru.KOI8-R > > /, which never got moved/deleted). > > I'm not sure that's actually the case. It seems to be related to the > above problem. It's odd that you're encountering this but it's not > being hit elsewhere. > > Is it somehow being evaluated twice or $(CURDIR) being carried over into > the sub-make which then expands? > > Cheers, > -- > James > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB > >
