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 26EA8158004 for ; Tue, 9 Jan 2024 09:59:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 55E1EE2B31; Tue, 9 Jan 2024 09:59:32 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 0CB28E2B2B for ; Tue, 9 Jan 2024 09:59:32 +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 Cc: pacho@gentoo.org Date: Tue, 09 Jan 2024 10:59:26 +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="=-5vGVVzk3AM0vsMBbaWWl" 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: 18664af8-0647-4c32-8c76-d4d4f68e2eca X-Archives-Hash: 59a0b5d42432afd821eed1e124c89894 --=-5vGVVzk3AM0vsMBbaWWl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2024-01-09 at 09:30 +0100, Florian Schmaus wrote: > On 06/01/2024 18.21, Micha=C5=82 G=C3=B3rny wrote: > > On Sat, 2024-01-06 at 18:01 +0100, Florian Schmaus wrote: > > > I really like the functionality of readme.gentoo-r1.eclass, as it > > > allows to communicate Gentoo-specific information about a package to > > > the user. Especially as it improves the signal-to-noise ratio of > > > messages arriving to our users. > > >=20 > > > However, readme.gentoo-r1.eclass will only show this information on > > > new installs, but not if the information changed. This is a major > > > drawback. Furthermore, readme.gentoo-r1.eclass does not provide an AP= I > > > to assemble the information via heredoc. > >=20 > > Are you implying that readme.gentoo-r1 is unfixable and you need to > > start over, and have a third generation of eclasses to install a readme > > file? >=20 > Not at all. See the second item of the TODO list in the eclass' descripti= on. >=20 > That said, both eclasses are rather small, >=20 Since when, 300 lines to install a README file is "small"? > > > The main item is doc compression. Right now, greadme.eclass defaults > > > to add the readme doc to the compression exclusion list via > > > "docompress -x". A mode where the readme doc is compressed, just as > > > readme.gentoo-r1.eclass does, can be activated by setting > > > _GREADME_COMPRESS. However, I believe this mode is fragile as it can > > > not be guaranteed that a binary for the used compression algorithms i= s > > > installed on the host [1]. > >=20 > > Dangling reference here. In any case, documentation compression is > > a standard feature of the package manager. If it doesn't work for > > whatever reason, I'd rather see you focus on find a good solution rathe= r > > than working it around via abusing `docompress -x`. =20 >=20 > The problem is the lack of a guarantee that the utilities required to=20 > decompress the file are available at installation time. It's user's responsibility to ensure that the tools set in their make.conf are available. > It gets even worse if you consider binpkgs, as you have surely read the= =20 > comment while looking at the code of the greadme.eclass. See FEATURES=3D-binpkg-docompress. That's the correct way to distribute binary packages. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-5vGVVzk3AM0vsMBbaWWl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmWdGP4SHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOHgcH/AscEm4B27arzHihuMCGiHSaAqG3yo/I yZtuXuVfAyaqYZfXIUUcOQOj7zn9uDCqLgwYm2WA4P+rCSX1OH2izRlla05grkh/ ir+9x3Mh5J5NT+zrI85IYKf/L29mETSH7dm2SfXrTifrR1MmJ4Qf9XSB7RUGZNv0 JzgSSCl0qCKjFimLXu6HD4qILHNYJ+YCjqAKT1lmJDlqbI+j4/cvyui+z6/pImTR Qo6nKxhpjIc7HLxwAWfLuMe6PXFpj3qYucw08odGtNVXqulosvrKg7YvXMxeNOrv yrg7ZBnWkiOr/9uvv8/jtIP03oDNwXMgBohOoJipAhzfHoxDuWCUaSY= =iMKu -----END PGP SIGNATURE----- --=-5vGVVzk3AM0vsMBbaWWl--