From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 220D3138334 for ; Tue, 27 Nov 2018 08:32:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CDB0CE0C62; Tue, 27 Nov 2018 08:32:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6A094E0C56 for ; Tue, 27 Nov 2018 08:32:44 +0000 (UTC) Received: from gentoo.org (unknown [IPv6:2001:980:3ff0:64:5054:ff:fe0b:7015]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: grobian) by smtp.gentoo.org (Postfix) with ESMTPSA id 99ED9335C6F for ; Tue, 27 Nov 2018 08:32:42 +0000 (UTC) Date: Tue, 27 Nov 2018 09:32:38 +0100 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format Message-ID: <20181127083238.GH28829@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1542453700.31427.2.camel@gentoo.org> <20181118091644.GA880@gentoo.org> <1542533931.1293.23.camel@gentoo.org> <20181118110048.GB880@gentoo.org> <1542792798.16894.17.camel@gentoo.org> <20181121104554.GB28829@gentoo.org> <20181126211353.GA30253@undo-autkin> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jRdC2OsRnuV8iIl8" Content-Disposition: inline In-Reply-To: <20181126211353.GA30253@undo-autkin> User-Agent: Mutt/1.10.1 (SunOS 5.11, VIM - Vi IMproved 8.1) Organization: Gentoo Foundation, Inc. X-Archives-Salt: 61da82b5-6df0-4c91-8fa4-3ad0e4a62e60 X-Archives-Hash: d25616c9aa6ee6ddb215b241f35d3e12 --jRdC2OsRnuV8iIl8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 26-11-2018 21:13:53 +0000, Andrey Utkin wrote: > On Wed, Nov 21, 2018 at 11:45:54AM +0100, Fabian Groffen wrote: > > We agree it is hackish, and we agree we can do without. You simply > > exaggerate the problem, IMO, which mostly isn't there, because it works > > fine today. It can also be solved today using shell tools. >=20 > I am sad that you don't see it as a productivity impediment that the > user is required to know the custom tooling to do even such a trivial > non-standard action as manual extraction. Huh? tar -jxf doesn't do the trick for you? > Maybe I will make myself look bad by admitting this, but I'm not meeting > your expectations. I use Gentoo for ~11 years, and for about one year I > am using my private binpkgs distributed to all my machines (i.e. I have > read binary package guide fair number of times, but I stopped rereading > it when I satisfied my needs). When in need, I still reached to trusty > tar, and I did not even know what are the names of special tools (a > toolchain?) qtbz2 and qxpak. >=20 > Just few days ago I messed with binpkgs for investigation purpose. I > just wanted to extract few to somewhere (definitely not into system > root), and read a core dump with GDB asking it to use those extracted > files for debug symbols. >=20 > Of course I used `tar xaf`, because what I know is that it's honest tbz2 > just with metadata appended. >=20 > # tar xaf boost-1.65.0.tbz2 > =20 > bzip2: (stdin): trailing garbage after EOF ignored >=20 > Exit code is 0. > But the notice is annoying (on subconscious level), because Silence Is > Golden - "when a program has nothing interesting or surprising to say, > it should shut up". You seem to contradict yourself. You didn't know the tools, yet you say you needed to, to unpack the files. But you show here you just unpacked the files without said knowledge. > > % head -c `grep -abo 'XPAKPACK' $EPREFIX/usr/portage/packages/sys-apps/= sed-4.5.tbz2 | sed 's/:.*$//'` $EPREFIX/usr/portage/packages/sys-apps/sed-4= =2E5.tbz2 | tar -jxf - > >=20 > > results in no warnings/errors from bzip about trailing garbage, possible > > thanks to the spec being smart enough about this. >=20 > Thanks, this is a very concise **custom tool** to handle current binpkg > format. As is tar followed by tar. The obvious advantage of the latter is that you don't get a warning which could trigger you into thinking something is wrong. So, in my opinion, that is a better way of doing it compared to the current way. > > Not having to do this, when under stress and pressure to restore a > > system to get it back into production, is a plus. Though, in that > > scenario the trailing garbage warning wouldn't have been that bad > > either. >=20 > When understress and pressure, the irrelevant warning is not bad? > I am sure it is really bad for operator's attention. I've been using Gentoo binpkgs for a long while, I think something like ~14 years ago when I used them extensively. Perhaps I'm an exception, but back then I knew already there was an extra bit attached to the tars, as were all my collegues around me back then. The fact it comes up now (as a surprise?) maybe means the knowledge has gone. So good thing we're replacing it with something easier to infer from inspecting it. Fabian --=20 Fabian Groffen Gentoo on a different level --jRdC2OsRnuV8iIl8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEELUvHd/Gtp7LaU1vuzpXahU5EQpMFAlv9ASYACgkQzpXahU5E QpN+pAgApWNjCcyz98DQETZzLc8kGfdJtBGNDUGMvOoeyNo+8iejOwSfn1s0P395 YXT3q9c7Ezz4YRUIz15i0g91FcAmfsMgkXC73LaGw1xMGhxfySYO1MuvTU8G2+5+ CnBO7qPrOSf+W4bXilGSOl5jE1v8LSXmJ4amCmIK9s7X9K92kxCFQMRbi0op0QHs QDqCBW22zM/BNJiNAAaamp20Uec+YadbFeZnEgOp/akELxAi/CHAUwZFdepQWe0H G6GMlw0Z3X190qPJ9SUB8d9w+oeovvsA97Dj+nkhm70qRO4K17lSS/yWfPiWyNWn igM/HyIlWceKa268PMhl0ecakBGNOw== =ylsF -----END PGP SIGNATURE----- --jRdC2OsRnuV8iIl8--