1 |
Hi Ionen, |
2 |
|
3 |
On 2022/06/10 12:03, Ionen Wolkens wrote: |
4 |
> On Fri, Jun 10, 2022 at 11:41:01AM +0200, Jaco Kroon wrote: |
5 |
>> Hi All, |
6 |
>> |
7 |
>> Currently checks for kernel options etc happen in pkg_setup, would it be |
8 |
>> possible to move this to pkg_pretend? |
9 |
> One problem with pkg_pretend is that it may not even be the right |
10 |
> kernel, e.g. it could be using a new gentoo-kernel that was just |
11 |
> emerged in the process. There's also USE=symlink which may lead |
12 |
> to an entirely non-configured kernel. So pkg_setup check is |
13 |
> essential and "moving" wouldn't be right. |
14 |
> |
15 |
> Copying can "somewhat" work, albeit it could check against different |
16 |
> kernels and also cause duplicated messages (former nvidia-drivers |
17 |
> ebuild used to even repeat messages /3/ times when some were fine |
18 |
> to ignore (aka, just a warning) -- but 3 rather than 2 was due to |
19 |
> the ebuild doing it wrong though). |
20 |
This makes sense. But would then absolutely require a syntax like |
21 |
use?option to be supported so that CHECK_CONFIG can just be set globally |
22 |
once. And that brings another can of worms ... unless there is a common |
23 |
mechanism to "resolve" that using a syntax similar to elsewhere, eg, a |
24 |
mechanism to reduce something like: |
25 |
|
26 |
CONFIG_CHECK="MODULES PCI ~CRC_CCITT oslec? ( ECHO )" |
27 |
|
28 |
to "MODULES PCI ~CRC_CCITT ECHO" if USE=oslec, and "MODULES PCI |
29 |
~CRC_CCITT" if USE=-oslec. |
30 |
>> Motivation: pkg_setup executes just prior to unpack, so if it fails |
31 |
>> here it could be after a lot of other work has already gone into other |
32 |
>> packages, breaking the full merge, it would thus be better to break early. |
33 |
>> |
34 |
>> A couple of packages (dahdi included, although, in-prep commit changes |
35 |
>> that to match the eclass) invoke special cases for CHECK_CONFIG, |
36 |
>> depending on USE flags, so for example this is going into dahdi now |
37 |
>> (variation of what was in pkg_pretend) |
38 |
>> |
39 |
>> use oslec && CHECK_CONFIG+=" ECHO" |
40 |
>> linux-mod_pkg_setup |
41 |
>> |
42 |
>> Most of the checks in linux-mod_pkg_setup (like ensuring kernel sources |
43 |
>> are prepped) makes sense to perform in pretend rather so that we know |
44 |
>> it's sorted prior to the first packages starting to merge, thus reducing |
45 |
>> risk of breakage once merges have initiated. |
46 |
>> |
47 |
>> There are a fair number of consumers in-tree that would need to be |
48 |
>> validated, but from a quick grep I did this morning looking for examples |
49 |
>> I *suspect* most of the consumers will not require any changes. |
50 |
> Ideally changing EXPORT_FUNCTIONS should be done on EAPI bumps rather |
51 |
> than trying to update every ebuilds. Lot of overlays use linux-mod |
52 |
> too and don't expect sudden API breakage assuming not using the eclass |
53 |
> in a way they weren't supposed to. |
54 |
|
55 |
I suspect the usage isn't as well defined as it could be, and as such |
56 |
(postgress, dahdi and qemu - to name but those I looked at this morning) |
57 |
are all using it in slightly different ways, all of them makes sense, |
58 |
and all of them suffers different shortcomings. It seems the majority |
59 |
of uses are in pkg_pretend with an explicit check_extra_config call, |
60 |
given what you said above ... |
61 |
|
62 |
Kind Regard, |
63 |
Jaco |