[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 23:39, Jonas Smedegaard <dr at jones.dk> wrote:
> On 12-03-02 at 11:15pm, Felipe Sateler wrote:
>> 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.
>
> Ohh, I get it now: debhelper.mk always works on per-package dirs whereas
> pd.mk does not.

Exactly. (well, actually it is debhelper on its own, but cdbs does
assume per package dirs in some places, like list-missing in utils.mk)

>
>> > 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.
>
> Yes, I agree that it _would_ make sense.
>
> Problem is the CDBS snippet is now out in the wild, and changing it will
> very likely cause failures!
>
> Luckily, we can probably assume pd.mk to only be used in puredata-* and
> pd-* packages, so it should be fairly simple to resolve which of them
> uses CDBS, get in touch with all authors, and coordinate the change.

With that heristic, and checking the small number of packages matched,
only the following use the pd snippet:

pd-iemambi
pd-iemmatrix
pd-osc
pd-readanysf
pd-zexy


All of these are single-binary packages, thus unaffected by this change.

-- 

Saludos,
Felipe Sateler