Re: [gentoo-dev] linux-mod - moving checks to pkg_pretend

[Ionen Wolkens]

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