Bug 286292 – linux-mod.eclass: migration to EAPI=2 required to fix binpkgs support

• Product: Gentoo Linux
• Status: VERIFIED FIXED

[Description Fabio Erculiani (RETIRED) 2009-09-24 20:05:05 UTC]

To completely fix binpkgs support for external linux kernel modules ebuilds it is required to port linux-info.eclass to EAPI=2. I decided to open a bug to start (hopefully) discussing this.
The main issue is that pkg_setup contains stuff NOT required by binpkgs (like kernel sources detection & misc checks).



Reproducible: Always

Steps to Reproduce:

[Comment 1 Robin Johnson 2010-01-10 09:40:03 UTC]

Why do we need to move to EAPI=2 for it? I think it's doable without requiring EAPI2.

[Comment 2 Fabio Erculiani (RETIRED) 2010-01-10 09:47:00 UTC]

Yes, that's also true.

[Comment 3 Fabio Erculiani (RETIRED) 2010-01-16 12:45:25 UTC]

Ebuilds using kernel-2.eclass execute .config checks against kernel sources, which is really unwanted on a binpkgs system for these reasons:

1. kernel sources may not be available
2. Portage calls pkg_setup for binpkgs too
3. pkg_setup may incorrectly fail for binpkgs due to 1 even if pkg has been already built (and depends? perhaps in future, since this is missing from Portage at the moment) against it (thus, passed the tests).
4. Making possible for ebuilds to use src_prepare (thus EAPI=2) would allow to move such tests away from pkg_setup.

Also CCing dev-portage. I don't know if the situation evolved since this bug was created.

[Comment 4 Robin Johnson 2010-01-16 18:22:57 UTC]

(In reply to comment #3)
> Ebuilds using kernel-2.eclass execute .config checks against kernel sources,
> which is really unwanted on a binpkgs system for these reasons:
kernel-2? I think you're in error here. kernel-2 is ONLY for installing kernel sources.

I think you meant linux-mod.eclass.

> 1. kernel sources may not be available
> 2. Portage calls pkg_setup for binpkgs too
> 3. pkg_setup may incorrectly fail for binpkgs due to 1 even if pkg has been
> already built (and depends? perhaps in future, since this is missing from
> Portage at the moment) against it (thus, passed the tests).
> 4. Making possible for ebuilds to use src_prepare (thus EAPI=2) would allow to
> move such tests away from pkg_setup.
> 
> Also CCing dev-portage. I don't know if the situation evolved since this bug
> was created.

The root of the problem is that in pkg_setup BEFORE we ever unpack anything, we need to make some checks.
For building from source, the present contents of pkg_setup is correct. We need a way to just not run them when we're installing a binpkg. NOT moving them to after src_unpack.

[Comment 5 Fabio Erculiani (RETIRED) 2010-01-16 19:05:42 UTC]

Yes sorry ;)

Either ways is fine for me.

[Comment 6 Zac Medico 2010-01-17 02:49:00 UTC]

(In reply to comment #3)
> Also CCing dev-portage. I don't know if the situation evolved since this bug
> was created.

The situation hasn't changed. We can do something about it in EAPI 4. It's bug 154495.

[Comment 7 Robin Johnson 2010-01-17 03:03:36 UTC]

pkg_setup_binary sounds good.

with the following logic:

if{emerging a binpkg && defined(pkg_setup_binary) {
 pkg_setup_binary
} elif(defined(pkg_setup)) {
 pkg_setup
}

Can we emulate it with the EMERGE_FROM variable in the meantime?

[Comment 8 Zac Medico 2010-01-17 03:07:57 UTC]

(In reply to comment #7)
> Can we emulate it with the EMERGE_FROM variable in the meantime?

I guess it wouldn't hurt, since you'll just be handling a case that's already "broken" anyway. Even though all package managers may not support it, it won't make the situation any worse for them.

[Comment 9 Robin Johnson 2010-01-17 04:08:08 UTC]

lxnay: linux-mod_pkg_setup_binary is done now, and works here with no kernel sources present.

However, we need to review ALL consumers of the linux-mod.eclass again, to ensure that they don't run any kernel-needing code in their own pkg_setup before calling linux-mod_pkg_setup.

[Comment 10 Fabio Erculiani (RETIRED) 2010-01-17 11:58:16 UTC]

I am going to review most of those ebuilds in the next days and attach info to #301251, thanks a lot!

[Comment 11 Zac Medico 2010-03-30 13:33:30 UTC]

*** Bug 312075 has been marked as a duplicate of this bug. ***

[Comment 12 DaggyStyle 2010-03-30 13:40:53 UTC]

any news on the issue? is the away around it for the time being?

[Comment 13 Zac Medico 2010-03-30 15:12:52 UTC]

(In reply to comment #12)
> any news on the issue? is the away around it for the time being?

I'm not really sure what should be done about the issue you reported in bug 312075. I thought it was related to this bug, but maybe not. I'll reopen and reassign it.

[Comment 14 Fabio Erculiani (RETIRED) 2010-04-21 08:41:26 UTC]

Since last linux-*.eclass rework, I'm not having issues with binpkgs anymore. I think we could close this bug.