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 67849138334 for ; Mon, 26 Nov 2018 21:14:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12AE4E0908; Mon, 26 Nov 2018 21:14:00 +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 ACB8FE08F1 for ; Mon, 26 Nov 2018 21:13:59 +0000 (UTC) Received: from undo-autkin (unknown [109.159.206.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: andrey_utkin) by smtp.gentoo.org (Postfix) with ESMTPSA id AFE54335DBF for ; Mon, 26 Nov 2018 21:13:57 +0000 (UTC) Date: Mon, 26 Nov 2018 21:13:53 +0000 From: Andrey Utkin To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format Message-ID: <20181126211353.GA30253@undo-autkin> 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> 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 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <20181121104554.GB28829@gentoo.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: 71686df9-5675-452e-a610-367b7bdd8f4f X-Archives-Hash: 9f90c1f594e3ab62c1d6f8f5ca31403d --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. 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. 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. 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. Of course I used `tar xaf`, because what I know is that it's honest tbz2 just with metadata appended. # tar xaf boost-1.65.0.tbz2 =20 bzip2: (stdin): trailing garbage after EOF ignored 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". > % head -c `grep -abo 'XPAKPACK' $EPREFIX/usr/portage/packages/sys-apps/se= d-4.5.tbz2 | sed 's/:.*$//'` $EPREFIX/usr/portage/packages/sys-apps/sed-4.5= =2Etbz2 | tar -jxf - >=20 > results in no warnings/errors from bzip about trailing garbage, possible > thanks to the spec being smart enough about this. Thanks, this is a very concise **custom tool** to handle current binpkg format. > 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. When understress and pressure, the irrelevant warning is not bad? I am sure it is really bad for operator's attention. --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKsBAEBCgCWFiEEQtXEeQ89N5Y1BX/FMEr79spYDpcFAlv8YhFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQy RDVDNDc5MEYzRDM3OTYzNTA1N0ZDNTMwNEFGQkY2Q0E1ODBFOTcYHGFuZHJleV91 dGtpbkBnZW50b28ub3JnAAoJEDBK+/bKWA6XpOUP/3uxk1iToekZ/wSJBA6NP8k4 xJ4ECvLUh01eBtC7EXpFkXPZhU0CI3Dr40vlUXpvou4PsNzB0ERBhfMokizyUFIN X2+3PRXJx3CzrYPKwavRYLnDSqfSFFlRnf9hGNMjjnN1cY07l9yDvka3lFpBNj1F IblXZKxkeehR/S9EbPdKP/X0tB9HPGrqAZsrOPY7qq2jtlGbuqNco0yv3+FnvwOS UwYED69Rf0SAH8oTm2W6+wFgRjfjMjmssnfdYZ7EGHHkpg5eCsQeX5O0aHvoI9VT 6J4m2NR7D0S7LVA3VCoh362A69lu0lxV6icFe79ZXEYKF1Xod8uKT38BlUokeuoE XQet911Xu8T3KhMvdXOsW9F8oGg6OuGAAXjaDPtoZmi1Ru2xOmx3aF9CKx6tRTSb cD1cC+SKuqGVdmXNpLPBQiOIaA+2pjhz1Sc0RpiW7E9yE36w4BG7dVeU39OnTXcw vtvRqWQ0Fog8VRD+wOHNLvVymSVmCa48BGygODINE1khCxg1QdvsH5bTodYN4f9C Gsnv/sRZ+E2Y1Oo7KyevmtVmvGGynsOYS8D5No2o3EQw0L+GYissFlD9IKAC0F+F kH7MwyhyJ6CnrlleiDGCEgiymDfskYtSjU36TQUtq5OV0UQH3evgBJdvqTZtkY98 C/57lGUoe9ZqsJd+kI1q =U8L2 -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1--