Date: Fri, 4 Apr 2014 11:45:47 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: Stripping of binaries (Was: Re: svn commit: r350052 - head/Mk) Message-ID: <20140404094546.GC78280@ivaldir.etoilebsd.net> In-Reply-To: <20140404085811.GA19897@FreeBSD.org> References: <201404032211.s33MBqWj021361@svn.freebsd.org> <20140404085811.GA19897@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 04, 2014 at 08:58:11AM +0000, Alexey Dokuchaev wrote: > On Thu, Apr 03, 2014 at 10:11:52PM +0000, Baptiste Daroussin wrote: > > New Revision: 350052 > > URL: http://svnweb.freebsd.org/changeset/ports/350052 > > QAT: https://qat.redports.org/buildarchive/r350052/ > >=20 > > Log: > > Prepend install(1) command with the STRIPBIN env defined to the proper > > STRIPBIN to allow cross-installation >=20 > I think it's good time to rethink our stripping policy/strategy at large,= as > it is kind of mess overall, and now I see the risk of it to become even m= ore > messy with introduction of cross-building. >=20 > So, we have ports with their own `do-install' targets, and binaries are > normally installed with INSTALL_(PROGRAM|LIB), which includes `-s' switch= by > default; passing STRIPBIN via env allows install(1) to call correct strip= (1) > in cross-case, right? >=20 > Other ports deploy files through a vendor's routine, which can be anythin= g, > from install(1) to cp(1) or tar(1) or cpio(1). Some of them try to strip > binaries during compilation; others do it on install, or may not do at al= l. >=20 > I've recently started to notice that folks strip binaries in `post-instal= l' > target. Frankly, I don't understand 1) why it is being done this way, and > 2) why it become so popular. It is not just ugly on its own, it is ugly = on > a much larger scale as it adds little, almost identical, imperative pieces > of code to *a lot* of Makefiles. What makes me wonder even more, this is > being done for staged ports! >=20 > I propose that, instead of adding hacks for `-s' feature of install(1) we > remove this switch completely from INSTALL_* knobs, and remove any manual > STRIP_CMD's from ports' Makefile. Let the files in $STAGEDIR be unstripp= ed, > there is nothing wrong with it; moreover, staging allows precisely for any > pre-package tuning, file cherry-picking, etc. >=20 > Stripping should be done by pkg(8) when generating final package (perhaps > subject to some NO_STRIP/NO_STRIP_FILES knob or something). This will al= so > ensure that correct strip(1) binary will be called, without exposing it to > install(1). It will also allow to consolidate stripping logic in one pla= ce > instead of having it scattered around the whole Ports Tree. >=20 > Makefiles should stay mostly declarative. Adding code there just does not > look right upfront. >=20 While I do agree with the problem you are spotting the solution is imho not= the one you propose at all. 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 st= age dir to be able to create some debug packages. - some badly written program/libraries only works when not stripped so we n= eed a way to declares (don't strip this) In my opinion stripping should not be done my pkg register/create at all but should be done globally by the ports framework, but having this done proper= ly and safely (fixing all the above listed problem) would need changing lot of things in bsd.port.mk and fixing lot of logic which cannot easily be done without a risk to break something Generally speaking the ports tree needs to grow up with more and more autom= ated concept like compressing manpages, stripping binaries, (compressing docs?), generating .py* (for python) and so one. Right now we have no clean framework to instrument that compress-man is a f= irst step but I will hate to add new target in a non automated way to implement = that. 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. I'm 100% pro-declarative only makefile :) regards, Bapt --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlM+f0oACgkQ8kTtMUmk6EzrQwCggvR5Vu9EbSz/XGXbYvXvYWdO jZIAoJzkvZUl4C03O2TqYuCpqdFiRLnG =VZ2a -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140404094546.GC78280>