On Fri, Jun 10, 2022 at 06:03:28AM -0400, Ionen Wolkens wrote: > 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
Actually, also need to consider the case where there's not even a kernel yet. e.g. `emerge gentoo-kernel-bin nvidia-drivers` would fail with pkg_pretend and work with pkg_setup So, if used, pretend would need to be (at least) non-fatal and just a warning. > 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 -- ionen
signature.asc
Description: PGP signature
