From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mail.openembedded.org (Postfix) with ESMTP id A347077DB1 for ; Thu, 1 Jun 2017 17:46:34 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP; 01 Jun 2017 10:46:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,280,1493708400"; d="scan'208";a="1137013088" Received: from kanavin-desktop.fi.intel.com (HELO [10.237.68.161]) ([10.237.68.161]) by orsmga001.jf.intel.com with ESMTP; 01 Jun 2017 10:46:31 -0700 To: Mark Hatle , openembedded-core@lists.openembedded.org References: From: Alexander Kanavin Message-ID: Date: Thu, 1 Jun 2017 20:44:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH 1/2] package_rpm.bbclass: use multithreaded xz compression X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 17:46:40 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06/01/2017 08:11 PM, Mark Hatle wrote: > On 6/1/17 10:15 AM, Alexander Kanavin wrote: >> RPM's default is single-threaded gz; the change greatly helps with >> both buildtimes (when there is a small number of large-sized packages) >> and disk space taken by resulting rpms. > > If you wnable XZ here, you need to make sure XZ compression is enabled within > rpm itself. (I know how that worked in rpm5, not sure how rpm4 does it -- it > may be enable that the binary be present to call out to.) rpm4 does not call out to any binary, it is linking against liblzma from xz package, if it can find it during configure. Xz was already in list of dependencies, so nothing needed to be done. Same for other compression schemes. > Finally I have not investigated parallel XZ, but in some cases the resulting > compressed file is different depending on compression artifacts due to > parallelization. (The compressed file is different, not the uncompressed content.) > > This can be a concern to some who want fully reproducible builds (from source). > So we need to make sure we have a way to disable this type of parallelization > --if-- it causes a problem with different contents. Let's first see if it is an actual concern for anyone. If the uncompressed contents is exactly same, I have difficulty seeing what is the problem specifically. Alex