On Fri, Mar 2, 2012 at 22:18, Jonas Smedegaard <d...@jones.dk> wrote: > On 12-03-02 at 09:35pm, Felipe Sateler wrote: >> PD uses cdbs_curdestdir, but that is set to debian/tmp in multiple >> binary packages. It should use debian/$package instead, to avoid >> calling strip and dpkg-shlibdeps to be called multiple times. >> >> This pollutes the build logs since pd externals usually have undefined >> references (they use symbols from the main pd binary), so they appear >> multiple times. > > cdbs_curdestdir resolves to whatever is destdir for current package. > > Yes, by default that is debian/tmp for multiple packages. It is > overridden like this: > > DEB_DESTDIR = $(CURDIR)/debian/$(cdbs_curpkg) > > ...but why do you file this as a bugreport?
Because calling dpkg-shlibdeps for all packages on a binary that is not included in all packages (just one) is clearly wrong. Mostly I'm concerned about the warning errors that pollute the other (maybe useful) output of dpkg-shlibdeps coming from the dh_shlibdeps call. > > Are you saying that the pd.mk snippet should _always_ use per-package > destdir? If so, are you certain that no existing package will break > when doing such radical change? I'm not certain (I can't know which packages use this), but it makes sense. debhelper -p option makes it take files from debian/$package as input[1]. Since these particular routines are working around dh_strip, dh_shlibdeps and dh_fixperms because of the odd suffix of the pd externals, it makes sense to operate on those directories too. debhelper(1) says about compat version 2: > In this mode, debhelper will consistently use debian/package as the package > tree > directory for every package that is built. There are no more changes in any of the compat level (save for an unrelated change in v7 concerning dh_install), so I guess it is very unlikely to break existing packages. [1] Well, this is only correct for dh_* calls after dh_install, if I understand correctly. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
