Problems are related to where distrobox is stashing a clblas and openblas package. It’s on the base system too, further complicating searches. I’ve tried all kinds of stuff with no luck. I hate the massive find command’s obfuscated ancient API of a full sized ANSI language specification. Python or C is easier than that junk.

A simple $ dnf where command seems like such an obvious thing even if it is an unrelated alias or function outside of dnf.

  • @Rand0mA
    5•1 year ago

    If you’re looking for the location of a package installed on your system, you can use the rpm command with the -ql option to list the files.

    For example:

    rpm -ql clblas Or rpm -ql openblas.

    You can use Python’s pip or C’s pkg-config (for C libraries) to get the installation paths.

    For Python packages:

    pip show clblas # Replace ‘clblas’ with the package name

    For C libraries using pkg-config:

    pkg-config --libs clblas # Replace ‘clblas’ with the library name

  • @INeedMana
    5•1 year ago

    Finding installation locations with rpm is the good approach but just for completeness sake, in order to search for files check locate.
    which is also good to know

    • @donio
      4•1 year ago

      The plocate implementation of locate in particular is very fast even with a large number of indexed files.

    • @j4k3OPEnglish
      0•1 year ago

      Like Rand0mA mentioned with $ rpm -ql, this turned out to be odd from a distrobox. IIRC this returned the location of some documentation but not the actual package. As far as I understand it, which and locate both seem to rely on the path variable to determine location. The blas packages I needed were just dependencies for an AI GUI interface. I’m not sure what they are exactly. They may be libraries without any executables. Dnf definitely knows where they are. If I try to reinstall the installation is skipped because the requirement is already satisfied. Dnf should not have the functionality to make this call without citing the local source of the package IMO.

      This type of issue has turned into such a mess I’m probably going to try nix for AI stuff at this point.

      • @INeedMana
        2•1 year ago

        Which uses PATH and that’s why it’s useful. It allows you to check which file will be executed and if you’re missing a path in PATH

        IIRC locate should have a db of files, so it should show paths.
        You can also do find / | grep -i blas but that might take a while

        • @j4k3OPEnglish
          2•1 year ago

          The problem with find is its read error nonsense, and from a distrobox container, it shows all instances of the package including those on the base system. Wherever dnf was placing the file, it was not in the PATH. I don’t know how that happened. It may be a bug in the distrobox configuration for Fedora 38. I gave up on it and tried nix on my base install as a parallel package manager option. That put a user file on the root partition and files everywhere. I didn’t fully understand this before installing and thought it was referring to permissions instead of location; a stupid oversight on my part. That is my last straw with this mess. I’m going back to immutable where I know exactly what is on the base system at all times and can simply roll back mistakes without dealing with constant backups.

          Thanks for the help.

        • @j4k3OPEnglish
          1•1 year ago

          deleted by creator