On Mon, 2010-09-13 at 16:34 +0200, Jonas Smedegaard wrote:
> On Mon, Sep 13, 2010 at 08:55:15AM -0400, Hans-Christoph Steiner wrote:
> >On Sep 13, 2010, at 6:06 AM, IOhannes m zmoelnig wrote:
> >>On 2010-09-12 19:27, Alessio Treglia wrote:
> >>>On Sun, Sep 12, 2010 at 7:08 PM, Hans-Christoph Steiner
> >>><h...@at.or.at> wrote:
> >>>>I noticed that you left debian/docs. Do you think that might
> >>>>with the README.txt in debian/links?
> >>>>Excellent! I'll remove the override_dh_strip targets. Is this a
> >>>>product of using dh_auto_install instead of make?
> >>>No, it isn't. The Makefile contains all that, dh_auto_install just
> >>>runs 'make install'.
> >>sorry to interrupt, but as i see it, the build process now
> >>unconditionally strips the binaries, which violates the debian-policy
> >>(4.9.1 DEB_BUILD_OPTIONS "nostrip")
> >>at least, if i compile with DEB_BUILD_OPTIONS="nostrip", the resulting
> >>binary "arraysize.pd_linux" will still be stripped.
> >That seems like something that debhelper should handle. Does it need
> >a separate install-strip Makefile target?
> debhelper optionally strips. It cannot "un-strip" if stripped by
> upstream build routines, as seems to be the case here.
Currently the strip is happening in the install target with the $(STRIP)
variable. I suppose it would be possible to set $(STRIP) to "touch",
that would work with the current Makefile.
All of these pd packages that I am uploading use the same Makefile
template. We wrote this Makefile with the expressed intention of making
it really easy to package properly. So what is debhelper looking for in
order to have separate install and strip capabilities?
pkg-multimedia-maintainers mailing list