Stripping of binaries (Was: Re: svn commit: r350052 - head/Mk)

[Bryan Drewery]

On 4/4/2014 5:38 AM, Alexey Dokuchaev wrote:
> On Fri, Apr 04, 2014 at 11:45:47AM +0200, Baptiste Daroussin wrote:
>> While I do agree with the problem you are spotting the solution is imho
>> not the one you propose at all.
> 
> pkg(8) just came on my mind first due to staging; I agree with you that
> universal, extendable `post-install" target/framework would probably be
> better for these things.
> 
>> To have a clean solution we have to get a long term view about the package
>> building.
>>
>> Here are the list of problems we have with stripping.
>> - .a are often installed in the stage in 444 mode, meaning you cannot
>>   strip them as a simple user after staging
>> - cross building involves a different strip binary
>> - in very long term we want to be able to extract the debug flags in the
>>   stage dir to be able to create some debug packages.
>> - some badly written program/libraries only works when not stripped so we
>>   need a way to declares (don't strip this)
> 
> Yes, the last bullet suggests that it's out of pkg(8) scope, and should be
> perhaps done in b.p.m. (it would need to look into Makefile, since putting
> some DONT_STRIP_THIS type of data into package manifest looks bogus).
> 
>> That said, if someone want to step up and write a "post-stage" framework to
>> easily plug new automated operation could then properly handle properly.
> 
> Do we have a wiki page on this?  If not, shall we create one?  I'd like to
> include excerpts of this discussion there.
> 
> ./danfe
> 

Ideally the implementation ends up in Mk/Scripts/*.sh too :)

I'm working on some new features and trying to stick to that. It's
making the code much cleaner and maintainable.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20140404/bf2b5b5a/attachment.sig>