uploaded 3 new pkgs: pd-arraysize, pd-beatpipe, pd-comport

Jonas Smedegaard dr at jones.dk
Mon Sep 13 16:56:38 UTC 2010


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 
>> >>><hans at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100913/c051fba6/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list