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