Summary: | base.eclass should not export src_unpack() in EAPI 2+ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Eclasses | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | jlec |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=463768 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 382323 |
Description
Michał Górny
2011-06-08 17:20:12 UTC
Suggesting removing it in EAPI 5. Ping. Could I get some opinion on this? @qa, you are the maintainer. Could we proceed here? I think the agreement ended up more like 'let's kill base.eclass with fire' and not change it anymore. (In reply to Michał Górny from comment #4) > I think the agreement ended up more like 'let's kill base.eclass with fire' > and not change it anymore. +1 It's unlikely that we would be able to fix the issue in place, and we shouldn't go for a base-r1.eclass. Yeah, I think we should focus on its removal instead of keeping it around. Looking at the counts $ grep --include='*.eclass' -r 'inherit.* base' /usr/portage/eclass/ | grep -vE ':[[:space:]]*#' | wc -l 19 $ grep --include='*.ebuild' -r 'inherit.* base' /usr/portage/ | grep -vE ':[[:space:]]*#' | wc -l 717 there are quite some left, seems like another task for the ongoing efforts list... How about a repoman warning and/or a deprecation warning? sci-* cleaned. (In reply to Justin Lecher from comment #7) > How about a repoman warning and/or a deprecation warning? Yeah, can do; but for this bug summary or base.eclass as a whole? (@creffett?) (In reply to Tom Wijsman (TomWij) from comment #9) > Yeah, can do; but for this bug summary or base.eclass as a whole? > (@creffett?) I found that the base.eclass was used for one maybe two reasons, PATCHES array and maybe the execution of epatch_user. Most of the other functionality is implemented in EAPI=5 so we can punt the whole eclass. What was again the reason that PATCHES array and epatch_user didn't made it into EAPI 5? (In reply to Justin Lecher from comment #10) > What was again the reason that PATCHES array and epatch_user didn't made it > into EAPI 5? We need a patch applying function in the package manager itself, and it was not ready at the time. It still isn't ready yet, although details how it should be implemented have become clearer. See bug 463768 comment 32. If we're considering eclasses inheriting base.eclass, I'd go for inlining necessary minimal support for PATCHES array. If we're considering ebuilds, either local 'epatch "${PATCHES[@]"' or just inline epatch calls. I don't think the global array makes that much of a difference really. (In reply to Tom Wijsman (TomWij) from comment #6) > Yeah, I think we should focus on its removal instead of keeping it around. > > Looking at the counts > > $ grep --include='*.eclass' -r 'inherit.* base' /usr/portage/eclass/ | grep > -vE ':[[:space:]]*#' | wc -l > 19 > $ grep --include='*.ebuild' -r 'inherit.* base' /usr/portage/ | grep -vE > ':[[:space:]]*#' | wc -l > 717 > down to 10 and 597 Let's focus on killing it completely (in EAPI 6?) instead. |