Re: [gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

[Michael Haubenwallner]

On 05/31/2018 12:58 AM, Zac Medico wrote:
> 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.

RDEPEND doesn't feel correct - see below.

>
>> 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.

Probably - with explicit "dependencies for merge and configuration phases"?
For consistency with DEPEND+RDEPEND, I can imagine BDEPEND+*BRDEPEND*.

>
>> 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?

In RDEPEND, they are provided as CHOST binaries (in EROOT), but they are
executed on the CBUILD machine during merge and configuration phases.

In BDEPEND, they are not guaranteed to be available with binary packages.

For a workaround (in another prefix-chaining portage patch), it might work to
guarantee BDEPEND be available even for merge and configuration phases, no?

-- 
Thanks!
/haubi/