1. Forum
  2. Usenet
  3. LINUX.DEBIAN.KERNEL

  • Re: Debian Kernel version and ABI in respect of #1040901

    From Bastian Blank@21:1/5 to Bastian Blank on Sun Jul 23 10:10:01 2023
    On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
    Please share your thoughts or if we have a better solution overall.

    After a lot of thinking, maybe a solution that allows for incompatible
    package updates without renames would be more useful. Something like:

    We uncouple the package names and ABI. The ABI will include the
    complete version, so every rebuild will change it. The package names
    can include just the upstream version, aka 6.1.1.

    This means:
    - Every module will be compatible always only with the exact version.
    - External modules needs rebuilds for every update of a image package.

    We already say: You need to reboot after kernel upgrade, because the ABI
    only provides compatibility from older modules to newer kernels. This
    would be now enforced by complete lack of compatibility.

    In the end this is what the RedHat world does AFAIK. They can install
    multiple versions of the same package at the same time, so you have just "kernel" installed in multiple versions.

    Regards,
    Bastian

    --
    Murder is contrary to the laws of man and God.
    -- M-5 Computer, "The Ultimate Computer", stardate 4731.3

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adrian Bunk@21:1/5 to Bastian Blank on Mon Jul 24 22:00:02 2023
    On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote:
    ...
    We uncouple the package names and ABI. The ABI will include the
    complete version, so every rebuild will change it.

    That's also what I meant with "It should only be impossible to make them co-installable".

    The package names
    can include just the upstream version, aka 6.1.1.

    I am not convinced about that part in all cases.

    This means:
    - Every module will be compatible always only with the exact version.
    - External modules needs rebuilds for every update of a image package.

    We already say: You need to reboot after kernel upgrade, because the ABI
    only provides compatibility from older modules to newer kernels. This
    would be now enforced by complete lack of compatibility.
    ...

    It is under our control when to not rename the packages,
    to prevent this issue for production systems.

    A binNMU for a perl transition might reach testing users,
    but these should not be production systems.

    When it takes 3 attempts in *stable-pu to get the kernel to build on all release architectures, only the last one will ever reach *stable.

    A policy question is that it might be a good idea to rename the packages
    when publishing a regression update for a DSA, that's the only place I see where this problem might otherwise reach production systems.

    Regards,
    Bastian

    cu
    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bastian Blank@21:1/5 to Adrian Bunk on Sun Sep 3 11:40:01 2023
    On Mon, Jul 24, 2023 at 10:36:47PM +0300, Adrian Bunk wrote:
    A policy question is that it might be a good idea to rename the packages
    when publishing a regression update for a DSA, that's the only place I see where this problem might otherwise reach production systems.

    Adding another modifier later is easy, as long as the overall setup
    works.

    Bastian

    --
    Oblivion together does not frighten me, beloved.
    -- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
    stardate 4770.3.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bastian Blank@21:1/5 to Bastian Blank on Sun Sep 3 11:40:01 2023
    On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote:
    After a lot of thinking, maybe a solution that allows for incompatible package updates without renames would be more useful. Something like:

    We uncouple the package names and ABI. The ABI will include the
    complete version, so every rebuild will change it. The package names
    can include just the upstream version, aka 6.1.1.

    And in addition: header and other support packages are not longer
    renamed. So they can only be installed once and need to be searched by
    the actual version of the image package.

    In any way, everything is weird and broken. We currently often run
    into uninstallable meta packages, due to the signing stuff adding a race condition between the availability of the header packages and the image packages. Then people tend to not reboot, so they are searching for
    older headers, which are already removed. And there is no really good solution.

    The only real solution would be to always bundle headers and images and
    install everything. But this will make everything 50MB larger and does
    not fit for things like the stripped down cloud kernels.

    Regards,
    Bastian

    --
    What kind of love is that? Not to be loved; never to have shown love.
    -- Commissioner Nancy Hedford, "Metamorphosis",
    stardate 3219.8

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