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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F1557158451 for ; Tue, 9 Jan 2024 10:43:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 16518E2AAE; Tue, 9 Jan 2024 10:43:31 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AA3D9E2AA7 for ; Tue, 9 Jan 2024 10:43:30 +0000 (UTC) Message-ID: Subject: Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Tue, 09 Jan 2024 11:43:25 +0100 In-Reply-To: References: <20240106170153.1581902-1-flow@gentoo.org> <1bd554f569029d8d99d315fa2d965ca63e76dbb7.camel@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-dTL4V34NM63C6PJ2KrfC" User-Agent: Evolution 3.50.3 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 X-Archives-Salt: ea3b9efe-b432-4728-96b4-6ccfb67b275f X-Archives-Hash: 97a7782d91953f275ccdb92b06b74f86 --=-dTL4V34NM63C6PJ2KrfC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2024-01-09 at 11:39 +0100, Florian Schmaus wrote: > Even if we say it is the user's fault, then the problem of handling a=20 > decompressor failure would still exist. The eclass does not gracefully= =20 > continue when decompressing the doc file, but instead it runs into a=20 > die(). To address this we would need to make unpacker.eclass and=20 > unpack() aware of nonfatal. The latter would require a PMS change. >=20 > Or, I could duplicate unpack logic --- which is probably a lot to=20 > account for the various compression options --- in the eclass. But I=20 > suspect be both do not want that. Perhaps this is the moment when you realize that there is no guarantee that unpacker.eclass and/or unpack will support the compression format set for docompress. The two were never intended to interact. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-dTL4V34NM63C6PJ2KrfC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmWdI00SHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOn8QH/isYDxIqCPNtjhrlYvYuExGmEIzZTVnU mBwKbRvwyf7S/6yjn/vEth0Y09ifKIRCqmCiTALjnUE2tiLG6/ox1dDxxDVjxuHD etaZGmRnEkaIoDyr1w7SqRSxS+ncgPxs5YnaJ39uJWNdhDp5No1gLxv3Ff/uG7vq pBRXhR49b5sgvxpdN3c3jpjb/mC8KQe6pxtgcd06WmXbfu91iicg/Tx8Su/P9Y9v V14TA+sTGtvfQomxoH0Srf9tcEbmZgCgrmCZMCP74eYyMmiJpjd/T4xuw2sZHSpg 1qq3rb0bjXzCMZ2Iu0Q2tekQZFIX5gNeFSCKtCkPYU2ioLAO/iBqU+g= =y3C4 -----END PGP SIGNATURE----- --=-dTL4V34NM63C6PJ2KrfC--