Hi All,

Currently checks for kernel options etc happen in pkg_setup, would it be possible to move this to pkg_pretend?

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.

If there are no objections, and time permitting, I could take a shot at
this and file a PR.

Kind Regards,
Jaco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmKjFvAACgkQskQGsLCs QzTwLwf9HDA1EUY8YwDltM1EDewckrd7GdwcSZbUP64XYIla8EZ0yMlpvBdpUQd8 UKi5ydhx3JyPOuR214hMDKIkdowd8BWUJZ6MVQNkjWn9dk1+Fjd1wfiQG1BbwFF9 QdBKBR06A1JTwgH/2x6yaCd9ssa523LmLXwDhPoC0me1jpmW0NWzfid36rxwbO++ ut49/7wOXv9khu2CV3zD3hHdBQ/mGw7w0FwdzDgx5ag4KGVa4K2xA4e0absxtx0V fzqzzkjlg/DtYaC7mOjqEERGHIm+7gx4qpHCqmm7iFv/imWoSxR9UnqlX1XDKVsH qtVppIhmCrbvWTb2ahn0yRZR4Tvv2g==
=SfDN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmKjF/AACgkQskQGsLCs QzTHVQgAs8fzY9v1nhxczhpXz2CLTh+TyE0AmNj/kHwTVxxm2l8ThjIKNBu3tL72 wTq4Nfp517fOM6dxHa3XzhIAR9Mm1lCLnWhMAGLr88fjf3+gaIBCn5YTay2pzp6B G1pFrtN73mJtpH4xs6067Hm04pDRf3Dh+0sr0FiqV4s3ynPmPeC9JYsoyrbqHgIS osVVVHRjBuOjlTL6wWXg0/yYbc5K/rzqiCDZUdwwjA/8O+5pDr51CyypzfYWojIK GqhhixOWn52UtCmxuYUB2Lzox89Z211vgb7V5vE55/ChThMyuX7oZAl25fsh3JvZ kNZaMYzRTZ3DsR8gpCkryypz0pl9Pw==
=Aczk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 2022/06/10 12:07, Ionen Wolkens wrote:

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.

Hmm.  So a newly installed kernel would probably always fail all checks.

Ok, I'm going to leave this as is, but move the DAHDI checks to
pkg_setup regardless just to be more in line with what I now understand
the INTENDED use was.

Kind Regards,
Jaco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)