On 06/04/2018 01:40 PM, Michał Górny wrote:
> W dniu śro, 30.05.2018 o godzinie 13∶49 +0200, użytkownik Michael
> Haubenwallner napisał:
>> 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!
> 
> I'm sorry for not replying earlier.  I meant to, but I failed to mark
> the mail and I've forgot about it.

This is what a (long) weekend is for: forget about it - at least for some time 
;)

>>
>> 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.
>>
>> Question now is: Is this wrong behaviour in the ebuild,
>> or is this something where EAPI 7 is still insufficient for?
> 
> It's a known deficiency discovered just a while too late to address it. 
> It comes from the fact that we never really had proper dependencies for
> pkg_*inst phases.  So far we've ignored the problem because our work-
> arounds were sufficient for our use cases but cross definitely needs
> something better.
> 
>> 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?
> 
> I think the 'closest' thing to right would be to use BDEPEND+RDEPEND. 
> It won't cover cross+binpkg but I guess it's as good as you can get.
> 

Having BDEPEND in RDEPEND will fix binpkg, but break cross again - which
BDEPEND aims to help firsthand (as far as I understood).

To get both binpkg and cross working, although not combined together,
what about something like this workaround:

EAPI=7
IUSE="+bindist"
BDEPEND="some-cbuild/tool"
RDEPEND="bindist? ( ${BDEPEND} )"

It should be easy for cross profiles to use.mask "bindist".

For cross (without binpkg), BDEPEND should still be around during pkg_*inst,
even if not specified per PMS.

-- 
/haubi/

Reply via email to