| Summary: | [Future EAPI] Install-time dependencies | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Michał Górny <mgorny> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, chewi, esigra, flow, haubi, pacho |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=317337 https://bugs.gentoo.org/show_bug.cgi?id=665074 https://bugs.gentoo.org/show_bug.cgi?id=685258 https://bugs.gentoo.org/show_bug.cgi?id=685916 https://github.com/gentoo/portage/pull/492 https://bugs.gentoo.org/show_bug.cgi?id=921580 |
||
| Whiteboard: | in-eapi-8 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380, 660308, 716334, 723278 | ||
(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. :) (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. (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? (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). (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. (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. 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(-) (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 :( 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'. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=11ffdd5a32b9bed132486efb939997b8749fbf9d commit 11ffdd5a32b9bed132486efb939997b8749fbf9d Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-12-22 20:32:41 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-06-05 08:55:35 +0000 EAPI 8 has install-time dependencies (IDEPEND) Bug: https://bugs.gentoo.org/660306 Signed-off-by: Michał Górny <mgorny@gentoo.org> [Updated as discussed in -pms mailing list] Signed-off-by: Ulrich Müller <ulm@gentoo.org> dependencies.tex | 25 +++++++++++++++++-------- eapi-differences.tex | 4 ++++ ebuild-env-vars.tex | 5 +++-- ebuild-vars.tex | 1 + eclasses.tex | 10 +++++----- metadata-cache.tex | 2 ++ 6 files changed, 32 insertions(+), 15 deletions(-) |
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.