Hi Ionen, On 2022/06/10 12:03, 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 > 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). This makes sense. But would then absolutely require a syntax like use?option to be supported so that CHECK_CONFIG can just be set globally once. And that brings another can of worms ... unless there is a common mechanism to "resolve" that using a syntax similar to elsewhere, eg, a mechanism to reduce something like:
CONFIG_CHECK="MODULES PCI ~CRC_CCITT oslec? ( ECHO )" to "MODULES PCI ~CRC_CCITT ECHO" if USE=oslec, and "MODULES PCI ~CRC_CCITT" if USE=-oslec. >> 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. I suspect the usage isn't as well defined as it could be, and as such (postgress, dahdi and qemu - to name but those I looked at this morning) are all using it in slightly different ways, all of them makes sense, and all of them suffers different shortcomings. It seems the majority of uses are in pkg_pretend with an explicit check_extra_config call, given what you said above ... Kind Regard, Jaco
