[Build-common-hackers] Bug#661962: Bug#661962: cdbs: PD class processes debian/tmp instead of debian/$package, causing multiple dpkg-shlibdeps invokations

[Felipe Sateler]

On Fri, Mar 2, 2012 at 22:18, Jonas Smedegaard <dr at 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