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 56F39138330 for ; Wed, 30 May 2018 22:58:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 97A03E093B; Wed, 30 May 2018 22:58:24 +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 3C1D4E0817 for ; Wed, 30 May 2018 22:58:24 +0000 (UTC) Received: from [10.128.13.172] (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 04296335C39; Wed, 30 May 2018 22:58:22 +0000 (UTC) Subject: Re: [gentoo-dev] EAPI 7, BDEPEND and pkg_*inst To: gentoo-dev@lists.gentoo.org, Michael Haubenwallner References: <5aa3997a-9b93-5882-1ad3-49eff04d45b0@gentoo.org> From: Zac Medico Message-ID: <8064914a-1e9a-b773-e03a-fe5a3c77fcdb@gentoo.org> Date: Wed, 30 May 2018 15:58:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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 In-Reply-To: <5aa3997a-9b93-5882-1ad3-49eff04d45b0@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: fbe05cd4-af5e-47b9-925e-8a372e068454 X-Archives-Hash: aa563d645854defc96af1497109d77d5 On 05/30/2018 04:49 AM, Michael Haubenwallner wrote: > Hi, > > HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining" > portage patch I've carried in prefix-overlay all the time, thank you for that! > > However, a first thing being unclear already came up when bumping EAPI 6 to 7: > > For example, the current app-misc/ca-certificates ebuild (EAPI 6) contains: > > # c_rehash: we run `c_rehash` > # debianutils: we run `run-parts` > RDEPEND="${DEPEND} > app-misc/c_rehash > sys-apps/debianutils" > > pkg_postinst() { > if [ -d "${EROOT}/usr/local/share/ca-certificates" ] ; then > # if the user has local certs, we need to rebuild again > # to include their stuff in the db. > # However it's too overzealous when the user has custom certs in place. > # --fresh is to clean up dangling symlinks > "${EROOT}"/usr/sbin/update-ca-certificates --root "${ROOT}" > fi > } > > Thing is, these RDEPENDs are not really required to "run" ca-certificates, but to > administrate it - which eventually is done on the CBUILD machine (from within the > ebuild, like in pkg_postinst currently), not necessarily on the CHOST machine. > > So I do not necessarily want these RDEPENDs to be installed on the CHOST machine, > given that they may not be executed from within the CBUILD machine at all. > > So the first idea is to move both RDEPENDs into BDEPEND. But then, they are > not guaranteed to be available during pkg_postinst - like for a binary package. Right, so it really belongs in RDEPEND *and* BDEPEND. > Question now is: Is this wrong behaviour in the ebuild, > or is this something where EAPI 7 is still insufficient for? If we want to tune the dependencies more finely, we'll need new EAPI. > When this is wrong (probably independent of EAPI 7 already) in the ebuild: > How can the ebuild get such a use case right, especially with EAPI 7? What's wrong with putting it in both? > Thanks! > /haubi/ > -- Thanks, Zac