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 706BA1581D3 for ; Sun, 2 Jun 2024 16:40:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF199E2B5D; Sun, 2 Jun 2024 16:40:29 +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 6F446E2A87 for ; Sun, 2 Jun 2024 16:40:29 +0000 (UTC) From: Ulrich Mueller To: Florian Schmaus Cc: gentoo-dev@lists.gentoo.org, pacho@gentoo.org Subject: Re: [gentoo-dev] [PATCH 0/4] Improve readme.gentoo-r1.eclass In-Reply-To: (Florian Schmaus's message of "Sun, 2 Jun 2024 18:12:40 +0200") References: <20240109083914.242561-1-flow@gentoo.org> <20240602135716.66992-1-flow@gentoo.org> Date: Sun, 02 Jun 2024 18:40:24 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 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: text/plain X-Archives-Salt: 22c721f1-848d-489e-9984-ae00e33de037 X-Archives-Hash: 05ef7088c4c94635b25ba52456a94f05 >>>>> On Sun, 02 Jun 2024, Florian Schmaus wrote: >> IMHO that's a very bad idea and will probably break ebuilds that rely >> on the current behaviour. > I pondered about this and its one of the reasons I'd rather start with > a fresh eclass. > That said, worst case scenario I could came up with is that the elog > message is printed twice. And this is also only the case if the ebuild > has readme.gentoo_print_elog *not* in pkg_postinst. However, the > readme.gentoo-r1.eclass documentation suggests you to put it in > pkg_postinst. > And if an ebuild has readme.gentoo_print_elog *in* pkg_postinst, which > should be true for nearly all ebuilds currently inheriting > readme.gentoo-r1, then you don't use the newly exported pkg_postinst > function (and the outcome of the exproted pkg_preinst is simply > ignored). > Bottom line is: exporting the functions should do no harm. It would break most ebuilds that inherit elisp and readme.gentoo-r1, because elisp_pkg_postinst would no longer be called.