1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • Re: [gentoo-dev] moving kernel config checks forward: potential config

    From Peter Stuge@21:1/5 to Robin H. Johnson on Mon Sep 27 21:30:01 2021
    Robin H. Johnson wrote:
    We have some set of packages (A) which collectively depend on one or
    more kernel options being set in specific ways, and the options need to REMAIN set if you want the packages to continue work.
    ..
    Can we consider moving the checks for set A somewhere else, such that we don't check the kernel config during package compile & install time, but
    only check it later?

    I only see one problem with this; that USE flags could influence which
    kernel options are required, which would be useful to know at/before
    compile time.


    It would need to keep long-term state about which packages want
    specific options set/unset/modular, as well as short-term state
    about the config from each boot.

    It's a cool idea. A standardized solution would be quite nice for the
    whole Linux ecosystem.


    //Peter

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Robin H. Johnson on Mon Sep 27 23:50:01 2021
    On Mon, 2021-09-27 at 19:14 +0000, Robin H. Johnson wrote:
    I wanted to break the prior thread to discuss the root issue.

    We have some set of packages (A) which collectively depend on one or
    more kernel options being set in specific ways, and the options need to REMAIN set if you want the packages to continue work.

    There are also a subset of packages (B), usually kernel modules themselves that will outright fail to compile if specific options are/are not set.

    Can we consider moving the checks for set A somewhere else, such that we don't check the kernel config during package compile & install time, but
    only check it later? This also meaningfully resolves that cases where
    the system that has package building isn't where the packages are being
    used.


    I'm not sure if I understand you correctly but if you mean not doing
    checks before compiling/installing, then I have to disagree. There is
    value in knowing about this kind of problems early (hey, that's why we
    have pkg_pretend in the first place!)

    There's certainly value in knowing 'I need to rebuild my kernel' early
    vs learning only after you've spent significant time waiting for some
    package to build.

    --
    Best regards,
    Michał Górny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin H. Johnson@21:1/5 to All on Tue Sep 28 01:00:01 2021
    On Mon, Sep 27, 2021 at 11:47:38PM +0200, Michał Górny wrote:
    Can we consider moving the checks for set A somewhere else, such that we don't check the kernel config during package compile & install time, but only check it later? This also meaningfully resolves that cases where
    the system that has package building isn't where the packages are being used.
    I'm not sure if I understand you correctly but if you mean not doing
    checks before compiling/installing, then I have to disagree. There is
    value in knowing about this kind of problems early (hey, that's why we
    have pkg_pretend in the first place!)
    Ebuilds should be able to call the tool (but it could be made optional
    easily), which does the checks MORE efficiently than the present eclass
    code. The ebuilds would be responsible for suitable warnings or failures
    based on the tool's output.

    E.g. maybe you're in a rescue environment and you know the tooling will
    work fine on your final environment.

    There's certainly value in knowing 'I need to rebuild my kernel' early
    vs learning only after you've spent significant time waiting for some
    package to build.

    One thing to this is if you're doing pkg_pretend for multiple packages
    in a single emerge call, the tool could greatly amortize the cost of the checks, as well as having them available after merge.

    Great thought I had would be this tool could ALSO run on boot and warn
    if some packages are unlikely to work

    --
    Robin Hugh Johnson
    Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
    E-Mail : [email protected]
    GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
    GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2
    Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it.

    iQKTBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAmFSS8NfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsQCXw/8C9M2l8I5LAjPqG0BbHdSnBBFyq8X5jVRWfuHVI7OIKddE132vBVrfMYl nsCNivlw3O6sWQr0N/AdmGBH7BOesZ+C5tAuHtEn9Eag7Gx3oTVsjYPJRYVeizTS oER0AEjSdAy3tI+3/rXaHMhtXVxozkbK3GNWJqUD55FmnTNv8X6OnbzZq2N2WiDb fTrlpLdzvmnVxIz/5xWvY7ki+BUMtoB7sEhWL0ld+1+KfyP9IpaFyoWdntEqeFCM zL29uSztjUd8/YBJoWKjlEv8BXWpAI247z5V9rPbAghAMqkikd6wlpPBhzQL98Jp A2DfF/t3UAGE3uIbP3f++fvZ4t5+o+hvrBc2mlSpTPtjnaUls40ganRux77FG/1/ 084h0BEkwBM5Xvx5akGG