1 |
On Fri, Jun 10, 2022 at 11:41:01AM +0200, Jaco Kroon wrote: |
2 |
> Hi All, |
3 |
> |
4 |
> Currently checks for kernel options etc happen in pkg_setup, would it be |
5 |
> possible to move this to pkg_pretend? |
6 |
|
7 |
One problem with pkg_pretend is that it may not even be the right |
8 |
kernel, e.g. it could be using a new gentoo-kernel that was just |
9 |
emerged in the process. There's also USE=symlink which may lead |
10 |
to an entirely non-configured kernel. So pkg_setup check is |
11 |
essential and "moving" wouldn't be right. |
12 |
|
13 |
Copying can "somewhat" work, albeit it could check against different |
14 |
kernels and also cause duplicated messages (former nvidia-drivers |
15 |
ebuild used to even repeat messages /3/ times when some were fine |
16 |
to ignore (aka, just a warning) -- but 3 rather than 2 was due to |
17 |
the ebuild doing it wrong though). |
18 |
|
19 |
> |
20 |
> Motivation: pkg_setup executes just prior to unpack, so if it fails |
21 |
> here it could be after a lot of other work has already gone into other |
22 |
> packages, breaking the full merge, it would thus be better to break early. |
23 |
> |
24 |
> A couple of packages (dahdi included, although, in-prep commit changes |
25 |
> that to match the eclass) invoke special cases for CHECK_CONFIG, |
26 |
> depending on USE flags, so for example this is going into dahdi now |
27 |
> (variation of what was in pkg_pretend) |
28 |
> |
29 |
> use oslec && CHECK_CONFIG+=" ECHO" |
30 |
> linux-mod_pkg_setup |
31 |
> |
32 |
> Most of the checks in linux-mod_pkg_setup (like ensuring kernel sources |
33 |
> are prepped) makes sense to perform in pretend rather so that we know |
34 |
> it's sorted prior to the first packages starting to merge, thus reducing |
35 |
> risk of breakage once merges have initiated. |
36 |
> |
37 |
> There are a fair number of consumers in-tree that would need to be |
38 |
> validated, but from a quick grep I did this morning looking for examples |
39 |
> I *suspect* most of the consumers will not require any changes. |
40 |
|
41 |
Ideally changing EXPORT_FUNCTIONS should be done on EAPI bumps rather |
42 |
than trying to update every ebuilds. Lot of overlays use linux-mod |
43 |
too and don't expect sudden API breakage assuming not using the eclass |
44 |
in a way they weren't supposed to. |
45 |
|
46 |
> |
47 |
> If there are no objections, and time permitting, I could take a shot at |
48 |
> this and file a PR. |
49 |
> |
50 |
> Kind Regards, |
51 |
> Jaco |
52 |
> |
53 |
> |
54 |
|
55 |
-- |
56 |
ionen |