From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7D41F13838B for ; Wed, 10 Sep 2014 20:57:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6435CE085C; Wed, 10 Sep 2014 20:57:44 +0000 (UTC) Received: from virtual.dyc.edu (mail.virtual.dyc.edu [67.222.116.22]) by pigeon.gentoo.org (Postfix) with ESMTP id 12391E085C for ; Wed, 10 Sep 2014 20:57:43 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) by virtual.dyc.edu (Postfix) with ESMTPSA id EB0D47E00E5 for ; Wed, 10 Sep 2014 16:57:42 -0400 (EDT) Message-ID: <5410BBDF.8050408@opensource.dyc.edu> Date: Wed, 10 Sep 2014 17:00:15 -0400 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 To: gentoo-catalyst@lists.gentoo.org Subject: Re: [gentoo-catalyst] [PATCH v2] stage1-controller.sh: Remove some old poor cleaning code References: <1409625101-27112-4-git-send-email-dolsen@gentoo.org> <1409634345-5378-1-git-send-email-dolsen@gentoo.org> <20140909113844.6220aee6.dolsen@gentoo.org> <5410876F.8000505@gentoo.org> In-Reply-To: <5410876F.8000505@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 6ee6aa73-6cf2-40a9-ad97-4ecc43ae86ba X-Archives-Hash: 2159abbd04f09eddaf6d9e5e6768c0b0 On 09/10/14 13:16, Rick "Zero_Chaos" Farina wrote: > On 09/09/2014 02:38 PM, Brian Dolbec wrote: >> On Mon, 1 Sep 2014 22:05:45 -0700 >> Brian Dolbec wrote: >> >>> This code had portage bin path hard coded. That path needed to be >>> changed for a new portage ebuild and install system. >>> After testing the origianl code and comparing it with some updated >>> code supplied by Douglas Freed. It turned out both code chunks >>> resulted in nothing being cleaned. >>> >>> Tested and confirmed by zero_chaos. >> >> I have gone over things more and tested the new find command. It does >> work on my host system. However, the question remains... DOES this >> particular cleaning operation NEED to be performed? >> >> With current the tree snapshot for my testing 20140829. It does not >> find anything to clean. BUT, will that remain the same in the future >> as pkgs are bumped? >> >> For safety, I'd be inclined to keep the find command (v1 of the >> patch) and clean any it does find just in case. >> > > If we truly need to remove these files, I don't think catalyst was ever > the place to do this. We have USE=static and USE=static-libs for a > reason. Randomly removing files from the filesystem was a hack then, > and if we are cleaning this up let's just remove it. If I want to build > things with USE=static or USE=static-libs then catalyst shouldn't be > pointlessly crippling my builds. > > v2 means one less horrible hack in catalyst, and one at a time is the > only way will remove all the horror. > > -Zero > I just did some testing here. You have to be very careful not to remove the wrong .a's else you break the toolchain. So I agree, remove the .a's in the ebuilds switched on USE=statlic-libs, and not in catalyst. The biggest .a's in stage1 are libpythonXX.a which are 3 to 4 MB, but the others are like a few hundred K's at most. The gain is a smaller stage, but the downside is headaches making sure we don't break something. So, to slim down stage1, see if you can get USE=static-libs in python's ebuilds and build USE=-static-libs. That itself will reduce that stage by about 8 MBs which is more than all the "expendable" .a's put together. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197