• [gentoo-user] How to produce broken binary packages

    From Alexander Puchmayr@21:1/5 to All on Sun Jan 15 12:20:02 2023
    Hi there,

    I just encountered a problem regarding binary packages and got some broken packages and I don't know how to solve this permanently; On my buildhost I compile all packages I need for several VMs and install only those packages I really need on the target machines.

    Problem combination:

    * net-fs/samba-4.15.12-r2 has a direct dependency to sys-libs/liburing.
    * dev-db/mariadb does not have a dependency to liburing, but during build, if liburing is available it will use it for some reason yielding a binary that links against it:

    Buildhost-server ~ # ldd /usr/sbin/mysqld
    linux-vdso.so.1 (0x00007ffec5b61000)
    libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 (0x00007fcfbd704000)
    libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fcfbd6c9000)
    liburing.so.2 => /usr/lib64/liburing.so.2 (0x00007fcfbd6c2000)
    ---

    Installing that package on a target VM does not install liburing, hence yielding a broken /usr/sbin/mysqld binary because the library is missing, and the reason why I still have a consistent system on my buildhost is because samba has it as dependency.

    A quick on-the-fly solution is either manually installing liburing and adding it to the world profile (@world is required otherwise emerge -c will remove it again), or install mariadb by compiling it (not using emerge -k). But all of them are somewhat unclean.

    A) Is this a problem in the ebuild script of mysql because not taking care of this?
    b) Is this a problem of mariadb's configure/make script because of implicitly using the library without being told so by ebuild?

    Alex

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Fink@21:1/5 to Alexander Puchmayr on Sun Jan 15 13:30:01 2023
    On Sun, 15 Jan 2023 12:14:29 +0100
    Alexander Puchmayr <alexander.puchmayr@linznet.at> wrote:

    Hi there,

    I just encountered a problem regarding binary packages and got some broken packages and I don't know how to solve this permanently; On my buildhost I compile all packages I need for several VMs and install only those packages I really need on the target machines.

    Problem combination:

    * net-fs/samba-4.15.12-r2 has a direct dependency to sys-libs/liburing.
    * dev-db/mariadb does not have a dependency to liburing, but during build, if liburing is available it will use it for some reason yielding a binary that links against it:

    Buildhost-server ~ # ldd /usr/sbin/mysqld
    linux-vdso.so.1 (0x00007ffec5b61000)
    libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 (0x00007fcfbd704000)
    libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fcfbd6c9000)
    liburing.so.2 => /usr/lib64/liburing.so.2 (0x00007fcfbd6c2000)
    ---

    Installing that package on a target VM does not install liburing, hence yielding a broken /usr/sbin/mysqld binary because the library is missing, and the reason why I still have a consistent system on my buildhost is because samba has it as dependency.

    A quick on-the-fly solution is either manually installing liburing and adding it to the world profile (@world is required otherwise emerge -c will remove it
    again), or install mariadb by compiling it (not using emerge -k). But all of them are somewhat unclean.

    A) Is this a problem in the ebuild script of mysql because not taking care of this?
    b) Is this a problem of mariadb's configure/make script because of implicitly using the library without being told so by ebuild?

    Alex


    Typically this is something that can be fixed in the ebuild, but
    ultimately it is a problem with automagic dependencies (check for the
    many automagic open bugs on bugs.gentoo.org or your described problem
    here: https://bugs.gentoo.org/878853)
    However I did not go to the build system of mariadb, and checked
    whether automatic discovery of a liburing can be explicitly turned
    on/off.

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