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 8E1F6138334 for ; Mon, 26 Nov 2018 19:51:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0C83DE09AD; Mon, 26 Nov 2018 19:51:17 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 A7A82E0975 for ; Mon, 26 Nov 2018 19:51:16 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 549A2335D27; Mon, 26 Nov 2018 19:51:14 +0000 (UTC) Message-ID: <1543261870.24857.6.camel@gentoo.org> Subject: Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Mon, 26 Nov 2018 20:51:10 +0100 In-Reply-To: References: <1542453700.31427.2.camel@gentoo.org> <1543258696.24857.4.camel@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-ajzwG7MlT7lzLggrbC4c" X-Mailer: Evolution 3.26.6 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 X-Archives-Salt: bf1ed37e-ba41-4325-b738-1133dfc6ef13 X-Archives-Hash: 70e7997c4f3dbc4b82deb753d91d6e0e --=-ajzwG7MlT7lzLggrbC4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2018-11-26 at 20:17 +0100, Ulrich Mueller wrote: > > > > > > On Mon, 26 Nov 2018, Micha=C5=82 G=C3=B3rny wrote: > > Specification > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The container format > > -------------------- > > The gpkg package container is an uncompressed .tar achive whose filenam= e > > should use ``.gpkg.tar`` suffix. This archive contains the following > > members, all placed in a single directory whose name matches > > the basename of the package file, in order: >=20 > I see no value in adding another directory indirection, and it will add > more overhead. Tar bomb is not a good design. Given tar padding, there will be no overhead unless the full path exceeds ustar limits which is unlikely. > Also, AFAICS the tar|tar pipeline that you previously > suggested won't work any more (or would at least require additional > arguments). I'm pretty sure the tar pipeline was actually written with account for the directory. >=20 > > 1. The package identifier file ``gpkg-1.txt`` (required). > > [...] > > The implementations must include a package identifier file named > > ``gpkg-1.txt``. The filename includes package format version; > > implementations should reject packages which do not contain this file > > as unsupported format. > > The file can have any contents. Normally, it should be empty. >=20 > If the file is empty, why is it named gpkg-1.txt (instead of just > gpkg-1)? >=20 *shrug*. I can make it 'gpkg-1' or 'gpkg.1' or whatever you want ;-). --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-ajzwG7MlT7lzLggrbC4c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlv8Tq5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQpyQRAAw1GKHDJIB7nb6PnwxmixuiK9+3EIXmjm28LGqzriAsSWpt2USW70DJUf Q66A8hlawCNlOgMJxKby86RmcxKnQRxP5Di0hb6lxOgTW+q7Eefe5/OLcGx0LsMd sJEcDdtiv+Y2COQi6nnO+5GZTFZJN9xFwTOKKODqLrXLzCqRGuIDQUJZYMHCTLEU 9xh9vDWeOU9J6b0E61rfdGrU0yAEcPASc1+5eWx0UKy5PayBVnraUpgwyoa1JEa9 iA5f6mnIAg/TdfL+Fn9gJocyKdVpf9jsaVnTvSoyOx6O806PlnmcoaO60pgp5fyK QpAvubp+rC2/qTohZpQW4AYWxo2ScJn1HDJB9ouiD6v0C5UC8NgiujfDcam2oQ08 c244jR1VxQaGusdgUH/DCNZwIzqw5Vg1tnmEnjQLvlKR/vXOkLJ9avtArk/rXUi8 go0BhdMujfkB1MnWuPW6lfQCGanBslBCP8ucmDjdbydJJeu7fbEu75EbKA44Vbpp 3aH6U/Mx35muheaUlaWInxCs+d0uhdLQkxHqScj2S9EJYL4l1HBQHS68PMpLqe2p f0ww4Atq4mIgu0Dl0abP2O8R8JyqwbhYYENrlmKGP9NgJ5l08x2p5eg064Yn2LeU qK4OEe2F8042de234C6xNEncq1CwW8D/ouGvtSV1LK+UcbfPLZI= =32Bk -----END PGP SIGNATURE----- --=-ajzwG7MlT7lzLggrbC4c--