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 DC80C1389E2 for ; Wed, 24 Dec 2014 18:38:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B871BE0848; Wed, 24 Dec 2014 18:38:02 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0D71CE0843 for ; Wed, 24 Dec 2014 18:38:01 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id l18so11930063wgh.2 for ; Wed, 24 Dec 2014 10:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=m3IpmgZp2tnIdKW+fQinmtPvM8WPMp92pno9WdBMTWM=; b=q3DT/3i7DY1mUe13cMEcBVmR5G9H4vF8W5+4DNHDnITqRlDn9x+TGKT2cUbs4MxN3P OvKzxP4g9gULhshy4OqXeKr8u0CB9bqmLKJMYuXmAeqk0oU9GR2oJED1Onzi6qcceyjV p2yQdGWmdKER4YLxpKFEhddFHkvo/DFQFZN+AJ9f7fN5yOkevHSTNwamdcl0BvTdzz2d sQWVbkYrbOz667XkC6S6T7EmGi+a62DniqBQPtEgH9GhkRomBpv1us6O4y3YoTV1w8Nh Mc4JKF47MJl7+piTJ3U5VL0NGsFN8IvpewVhaaw9yxsYr63OZtQ748WZdVY2z078fBAe RyDQ== X-Received: by 10.180.206.165 with SMTP id lp5mr54035140wic.83.1419446280777; Wed, 24 Dec 2014 10:38:00 -0800 (PST) Received: from ?IPv6:2001:1418:100:558::2? (cl-1369.trn-01.it.sixxs.net. [2001:1418:100:558::2]) by mx.google.com with ESMTPSA id u9sm32491159wjy.37.2014.12.24.10.37.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Dec 2014 10:37:59 -0800 (PST) Message-ID: <549B07C9.9090006@gmail.com> Date: Wed, 24 Dec 2014 19:36:57 +0100 From: "vivo75@gmail.com" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [RFC] New file layout for PKGDIR and binhosts References: <549A1C31.8040500@gentoo.org> <549A4C25.9050000@gentoo.org> <549A75C5.70600@gentoo.org> <549AAB08.2050908@gmail.com> <549AE4C4.3080306@gentoo.org> In-Reply-To: <549AE4C4.3080306@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: ab2b38a1-eefb-43fc-b59a-db4ead4daed8 X-Archives-Hash: 243aec6627e1a5a2c18c4ed581642ecd Il 24/12/2014 17:07, Zac Medico ha scritto: > On 12/24/2014 04:01 AM, vivo75@gmail.com wrote: >> Il 24/12/2014 09:13, Zac Medico ha scritto: >>>> I like this (and it has been a long time coming). What format are we >>>>> going to store the metadata of the use flag combinations and the rest? >>> The current approach is to store the data in an xpak segment that is >>> appended to the end of the tbz2 file. The $PKGDIR/Packages files serves >>> as a cache for the essential parts of the xpak data that are used in >>> dependency calculations. >>> >> I'd like to see the xpak data being put in it's own file at the >> _beginning_ of the tar file. >> >> tar -Jcf \ >> ${PKGDIR}/${CATEGORY}/${PN}/${PF}-${COUNTER}.xpak \ >> tmp/${CATEGORY}:${PN}:${PF}-${COUNTER}.xpak \ >> *all_the_other_stuff* >> >> this way reading it could be faster on some media and filesystem and it >> would not deviate from the standard tar. > There wouldn't be any benefit, because the data is practically always > read from the $PKGDIR/Packages cache anyway. The cache is generated when > the package is built, and the rate-limiting step there is the building > of the package. ack, and what about emerge on destination host? >> Being in /tmp/ is only for commodity but the place is debatable. >> Instead the fact it _must_ be the first file it's not, in a sequential >> archive file like tar some things depend on it. > With the current approach, the xpak segment is not part of the tar file. > The tar file is compressed, and the xpak segment is appended to the end > of the resulting bzip2 file. > >> seem to be the right time to do the change, since tool need to be >> rewritten anyway, but I'll leave to you analyze the fallout of this change. > There will be zero benefits from doing that. I see at least two however admittedly not too big 1) I see having a canonical tarball as an advantage, opposed to be forced to use /usr/bin/{qtbz2,qxpak} 2) there is a small benefit in space (which increase using xz) for bigger packages it would be smaller in percentage. -rw-r--r-- 1 root root 8720 24 dic 18.25 linuxtv-dvb-headers-5.8.tar.bz2 -rw-r--r-- 1 root root 9691 24 dic 18.07 linuxtv-dvb-headers-5.8.tbz2 this has been obtained unpacking the xpak _and_ environment.bz2 (to avoid double compression) and putting them in a subdirectory ls -l tmp/linuxtv-dvb-headers-5.8/ usr tmp/linuxtv-dvb-headers-5.8/: total 80 -rw-r--r-- 1 root root 11 Dec 24 18:20 BUILD_TIME -rw-r--r-- 1 root root 8 Dec 24 18:20 CATEGORY -rw-r--r-- 1 root root 2 Dec 24 18:20 DEFINED_PHASES -rw-r--r-- 1 root root 52 Dec 24 18:20 DESCRIPTION -rw-r--r-- 1 root root 2 Dec 24 18:20 EAPI -rw-r--r-- 1 root root 394 Dec 24 18:20 FEATURES -rw-r--r-- 1 root root 1 Dec 24 18:20 IUSE -rw-r--r-- 1 root root 30 Dec 24 18:20 KEYWORDS -rw-r--r-- 1 root root 24 Dec 24 18:20 PF -rw-r--r-- 1 root root 31 Dec 24 18:20 RDEPEND -rw-r--r-- 1 root root 2 Dec 24 18:20 SIZE -rw-r--r-- 1 root root 2 Dec 24 18:20 SLOT -rw-r--r-- 1 root root 65 Dec 24 18:20 USE -rw-r--r-- 1 root root 22859 Dec 24 18:21 environment -rw-r--r-- 1 root root 443 Dec 24 18:20 linuxtv-dvb-headers-5.8.ebuild -rw-r--r-- 1 root root 7 Dec 24 18:20 repository usr: total 9 drwxr-xr-x 3 root root 3 Dec 5 02:42 src