From owner-svn-ports-head@FreeBSD.ORG  Fri Apr  4 10:38:52 2014
Return-Path: <owner-svn-ports-head@FreeBSD.ORG>
Delivered-To: svn-ports-head@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1033)
 id D245D2E1; Fri,  4 Apr 2014 10:38:52 +0000 (UTC)
Date: Fri, 4 Apr 2014 10:38:52 +0000
From: Alexey Dokuchaev <danfe@FreeBSD.org>
To: Baptiste Daroussin <bapt@FreeBSD.org>
Subject: Re: Stripping of binaries (Was: Re: svn commit: r350052 - head/Mk)
Message-ID: <20140404103852.GA67976@FreeBSD.org>
References: <201404032211.s33MBqWj021361@svn.freebsd.org>
 <20140404085811.GA19897@FreeBSD.org>
 <20140404094546.GC78280@ivaldir.etoilebsd.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140404094546.GC78280@ivaldir.etoilebsd.net>
User-Agent: Mutt/1.5.22 (2013-10-16)
Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org,
 ports-committers@freebsd.org
X-BeenThere: svn-ports-head@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SVN commit messages for the ports tree for head
 <svn-ports-head.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-ports-head>,
 <mailto:svn-ports-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-ports-head/>
List-Post: <mailto:svn-ports-head@freebsd.org>
List-Help: <mailto:svn-ports-head-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-ports-head>,
 <mailto:svn-ports-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 10:38:52 -0000

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