Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 660306 (IDEPEND) - [Future EAPI] Install-time dependencies
Summary: [Future EAPI] Install-time dependencies
Status: CONFIRMED
Alias: IDEPEND
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: feasible-for-next-eapi
Keywords:
Depends on:
Blocks: future-eapi 716334 723278
  Show dependency tree
 
Reported: 2018-07-03 21:51 UTC by Michał Górny
Modified: 2020-06-18 14:59 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-07-03 21:51:42 UTC
After approving EAPI 7, we quickly realized we've missed an important limitation in our BDEPEND implementation: we can't properly express them for pkg_* phases.  In fact, we always lacked proper way of expressing dependencies for pkg_{pre,post}inst phases.

So far we've been able to get away with it by stating that RDEPEND is satisfied there.  However, that's far from perfect -- in the end, we may end up keeping things that are needed purely install-time (e.g. cache updaters) installed.

Sadly, this doesn't really work for cross since most of the time we actually want CBUILD class of dependencies at install time.  We certainly do not have BRDEPEND, and given that there's really no reason to have CBUILD deps at runtime, we don't want to add it.

Therefore, I think it'd be good to kill two birds with one stone and finally introduce separate install-time dependencies.  This raises a few questions:

1. Do we need split CBUILD/CHOST install-time dependencies?  I suppose there are use cases both for stuff that can be run from CBUILD, and for stuff that can only work within CHOST.

2. Are install-time dependencies expected to be satisfied in prerm/postrm?  I'm not sure if Portage uses any sane removal order right now.

3. Do we need some dep class for pkg_setup as well?  Given that normally deps are required to be installed before pkg_setup is run, should we extend install-time deps to apply to it as well?


If we go for it the full way, we'd either introduce two new variables:

  IDEPEND - install-time dependencies for CHOST
  BIDEPEND (yay!) - install-time dependencies for CBUILD

Of course, it'd be probably better to go for the labels at this point but that's a separate topic to discuss.
Comment 1 Ulrich Müller gentoo-dev 2018-10-02 06:36:58 UTC
(In reply to Michał Górny from comment #0)
> Therefore, I think it'd be good to kill two birds with one stone and finally
> introduce separate install-time dependencies.  This raises a few questions:
> 
> 1. Do we need split CBUILD/CHOST install-time dependencies?  I suppose there
> are use cases both for stuff that can be run from CBUILD, and for stuff that
> can only work within CHOST.

Aren't CHOST dependencies covered by RDEPEND already? At least table 8.1 seems to suggest so: https://projects.gentoo.org/pms/7/pms.html#x1-68001r1

> 2. Are install-time dependencies expected to be satisfied in prerm/postrm? 
> I'm not sure if Portage uses any sane removal order right now.

That might be asking for trouble:
- In order to remove a package, do we want to require installation of another package?
- The install-time dependency could be gone at the time of removal. (Also the ebuild of the to-be-removed package may be gone, so even dynamic dependencies won't help.)

> 3. Do we need some dep class for pkg_setup as well?  Given that normally
> deps are required to be installed before pkg_setup is run, should we extend
> install-time deps to apply to it as well?

No, only system set in pkg_setup (and pkg_pretend).

> If we go for it the full way, we'd either introduce two new variables:
> 
>   IDEPEND - install-time dependencies for CHOST
>   BIDEPEND (yay!) - install-time dependencies for CBUILD

See above, I believe that RDEPEND for CHOST and IDEPEND for CBUILD may be enough.

> Of course, it'd be probably better to go for the labels at this point but
> that's a separate topic to discuss.

There are 26 letters in the alphabet. :)
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-10-03 08:26:37 UTC
(In reply to Ulrich Müller from comment #1)
> (In reply to Michał Górny from comment #0)
> > Therefore, I think it'd be good to kill two birds with one stone and finally
> > introduce separate install-time dependencies.  This raises a few questions:
> > 
> > 1. Do we need split CBUILD/CHOST install-time dependencies?  I suppose there
> > are use cases both for stuff that can be run from CBUILD, and for stuff that
> > can only work within CHOST.
> 
> Aren't CHOST dependencies covered by RDEPEND already? At least table 8.1
> seems to suggest so: https://projects.gentoo.org/pms/7/pms.html#x1-68001r1

My question wasn't whether we could get away without doing it but whether we'd have real use cases benefitting from the split.

> > 2. Are install-time dependencies expected to be satisfied in prerm/postrm? 
> > I'm not sure if Portage uses any sane removal order right now.
> 
> That might be asking for trouble:
> - In order to remove a package, do we want to require installation of
> another package?

Makes sense.  Not that this exactly this clear right now but regutting Portage would never happen, so no point in pretending otherwise.
Comment 3 Ulrich Müller gentoo-dev 2018-10-03 15:14:07 UTC
(In reply to Michał Górny from comment #2)
> (In reply to Ulrich Müller from comment #1)
> > Aren't CHOST dependencies covered by RDEPEND already? At least
> > table 8.1 seems to suggest so:
> > https://projects.gentoo.org/pms/7/pms.html#x1-68001r1
> 
> My question wasn't whether we could get away without doing it but
> whether we'd have real use cases benefitting from the split.

I don't doubt that there are CBUILD type dependencies needed only during installation, like updaters for caches or catalogues.

However, are there examples of CHOST type dependencies, that are needed during installation but not at runtime? And if the answer to that question is yes, are they common enough to justify the additional complexity introduced by yet another dependency type?
Comment 4 Ulrich Müller gentoo-dev 2019-05-07 10:25:59 UTC
(In reply to Ulrich Müller from comment #3)
> However, are there examples of CHOST type dependencies, that are needed
> during installation but not at runtime?

No examples given since half a year, so let's assume that there are none. Getting away with RDEPEND for this might be better than further inflation of dependency types. (Also, regarding Exherbo type labels, I think that ship has sailed with our introduction of the BDEPEND variable.)

AFAICS, the examples in bug 685258 are c_rehash and run-parts, which are of CBUILD type (they only appear in DEPEND because the ebuild in question is EAPI 6).
Comment 5 Michael Haubenwallner gentoo-dev 2019-05-07 10:57:05 UTC
(In reply to Ulrich Müller from comment #4)
> AFAICS, the examples in bug 685258 are c_rehash and run-parts, which are of
> CBUILD type (they only appear in DEPEND because the ebuild in question is
> EAPI 6).

I fail to see how EAPI 7 would help here: c_rehash and run-parts are in RDEPEND for the binary package, where BDEPEND does not apply.
Comment 6 Ulrich Müller gentoo-dev 2019-05-07 11:24:11 UTC
(In reply to Michael Haubenwallner from comment #5)
> (In reply to Ulrich Müller from comment #4)
> > AFAICS, the examples in bug 685258 are c_rehash and run-parts, which are of
> > CBUILD type (they only appear in DEPEND because the ebuild in question is
> > EAPI 6).
> 
> I fail to see how EAPI 7 would help here: c_rehash and run-parts are in
> RDEPEND for the binary package, where BDEPEND does not apply.

Right, EAPI 7 won't help. My point was that these are CBUILD type dependencies, i.e., they are executed in pkg_postinst on the build machine.
Comment 7 Larry the Git Cow gentoo-dev 2019-08-30 14:52:54 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/api.git/commit/?id=b3e60322d5ce4d0131f6378e6b135c7219748d6c

commit b3e60322d5ce4d0131f6378e6b135c7219748d6c
Author:     Alec Warner <antarus@gentoo.org>
AuthorDate: 2019-08-30 14:51:45 +0000
Commit:     Alec Warner <antarus@gentoo.org>
CommitDate: 2019-08-30 14:52:31 +0000

    Remove http mirror.
    
    Bug: https://bugs.gentoo.org/660306
    Signed-off-by: Alec Warner <antarus@gentoo.org>

 files/mirrors/distfiles.xml | 1 -
 1 file changed, 1 deletion(-)
Comment 8 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2019-08-30 14:53:51 UTC
(In reply to Larry the Git Cow from comment #7)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/data/api.git/commit/
> ?id=b3e60322d5ce4d0131f6378e6b135c7219748d6c
> 
> commit b3e60322d5ce4d0131f6378e6b135c7219748d6c
> Author:     Alec Warner <antarus@gentoo.org>
> AuthorDate: 2019-08-30 14:51:45 +0000
> Commit:     Alec Warner <antarus@gentoo.org>
> CommitDate: 2019-08-30 14:52:31 +0000
> 
>     Remove http mirror.
>     
>     Bug: https://bugs.gentoo.org/660306
>     Signed-off-by: Alec Warner <antarus@gentoo.org>
> 
>  files/mirrors/distfiles.xml | 1 -
>  1 file changed, 1 deletion(-)

Er, sorry I attached the wrong bug :(
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-16 12:56:41 UTC
To rehash, let's limit this bug to a single dependency type (IDEPEND?) that indicates dependencies installed to CBUILD for pkg_*inst (and preserved for pkg_*rm), i.e. basically 'CBUILD RDEPEND'.