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

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

[Michael Haubenwallner]

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.

Question now is: Is this wrong behaviour in the ebuild,
or is this something where EAPI 7 is still insufficient for?

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?

Thanks!
/haubi/

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

[Zac Medico]

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

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

[Michael Haubenwallner]

[-- Attachment #1.1: Type: text/plain, Size: 2719 bytes --]


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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

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.

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

-- 
Best regards,
Michał Górny

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

[Michael Haubenwallner]

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/

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

[Zac Medico]

On 06/05/2018 01:26 AM, Michael Haubenwallner wrote:
> On 06/04/2018 01:40 PM, Michał Górny wrote:
>> 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.

If BDEPEND isn't around, you can use the emerge --with-bdeps=y option to
handle this case.
-- 
Thanks,
Zac