On Mon, Sep 13, 2010 at 10:52:57AM -0400, Hans-Christoph Steiner wrote:
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 >>>>conflict with the README.txt in debian/links?
>>>
>>>Fixed: >>>http://git.debian.org/?p=pkg-multimedia/pd-arraysize.git;a=commitdiff;h=7a67
>>>
>>>>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?

Normally, Debian packaging routines disable any stripping done during upstream build routines. Patching it away if need be.

Or, at least this was the case in the good old days...

With the introduction of short-form dh, debhelper works *both* after upstream build routines as in the old days, and *also* acts as initiator of upstream build routines.

If you insist on stripping as part of upstream build routines, it might now be possible to instruct recent releases of debhelper to control that. I really don't know the details of that, and I feel it is the wrong approach (even with short-form dh).

I recommend to do the following:

  * Make upstream build routines support not doing any stripping
  * Let debhelper do its work - it strips when needed
* If debhelper miss stripping some files (e.g. due to unusual naming) then *still* avoid doing it in upstream build routines, but instead extend the Debian debian/rules file to do it - read Policy for example routine to use to properly respect build flags


Hope that helps.

 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Reply via email to