Bug 370701 – base.eclass should not export src_unpack() in EAPI 2+

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Michał Górny 2011-06-08 17:20:12 UTC]

The src_unpack() function in base.eclass is equivalent to what PMS specifies for standard src_unpack(), and it might randomly override other eclasses. I think it should be not exported in EAPIs 2+.

[Comment 1 Michał Górny 2011-09-08 22:18:27 UTC]

Suggesting removing it in EAPI 5.

[Comment 2 Michał Górny 2011-11-30 16:27:44 UTC]

Ping. Could I get some opinion on this?

[Comment 3 Justin Lecher (RETIRED) 2014-01-04 18:02:51 UTC]

@qa, you are the maintainer. Could we proceed here?

[Comment 4 Michał Górny 2014-01-04 19:23:37 UTC]

I think the agreement ended up more like 'let's kill base.eclass with fire' and not change it anymore.

[Comment 5 Ulrich Müller 2014-01-04 19:50:52 UTC]

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

[Comment 6 Tom Wijsman (TomWij) (RETIRED) 2014-01-04 20:44:11 UTC]

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

[Comment 7 Justin Lecher (RETIRED) 2014-01-06 13:45:54 UTC]

How about a repoman warning and/or a deprecation warning?

[Comment 8 Justin Lecher (RETIRED) 2014-01-06 15:40:49 UTC]

sci-* cleaned.

[Comment 9 Tom Wijsman (TomWij) (RETIRED) 2014-01-07 00:34:42 UTC]

(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?)

[Comment 10 Justin Lecher (RETIRED) 2014-01-07 07:11:34 UTC]

(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?

[Comment 11 Ulrich Müller 2014-01-07 07:58:02 UTC]

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

[Comment 12 Michał Górny 2014-01-07 15:57:46 UTC]

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.

[Comment 13 Justin Lecher (RETIRED) 2014-07-23 14:58:35 UTC]

(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

[Comment 14 Michał Górny 2015-10-24 08:58:05 UTC]

Let's focus on killing it completely (in EAPI 6?) instead.