Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 286292 - linux-mod.eclass: migration to EAPI=2 required to fix binpkgs support
Summary: linux-mod.eclass: migration to EAPI=2 required to fix binpkgs support
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Kernel Miscellaneous
URL:
Whiteboard:
Keywords:
Depends on: 154495 301251
Blocks:
  Show dependency tree
 
Reported: 2009-09-24 20:05 UTC by Fabio Erculiani (RETIRED)
Modified: 2010-07-08 11:37 UTC (History)
3 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 Fabio Erculiani (RETIRED) gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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) gentoo-dev 2010-01-10 09:47:00 UTC
Yes, that's also true.
Comment 3 Fabio Erculiani (RETIRED) gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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) gentoo-dev 2010-01-16 19:05:42 UTC
Yes sorry ;)

Either ways is fine for me.
Comment 6 Zac Medico gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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) gentoo-dev 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 gentoo-dev 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 gentoo-dev 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) gentoo-dev 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.