libsolv breaks zypper when installed via conda as root user #94
Labels
bug
Something isn't working
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Solution to issue cannot be found in the documentation.
Issue
Scenario: given some form of conda (including miniforge) is installed as root on an openSUSE or SLES machine. When running commands that require a repository cache refresh, such as
zypper refresh, the zypper command fails to cache the repository metadata.The reason for this is due to zypper calling
repo2solvto convert the repository metadata into a .solv file. SUSE ships a compiled repo2solv as/usr/bin/repo2solv, but conda puts itself first on thePATHwhen integrated into the shell.condanow shipslibsolvas part of the libmamba dependency solver, thuslibsolvgets installed into the base conda environment, including a copy ofrepo2solv.Since conda puts itself (and its
$CONDA_LOCATION/binfolder) first on thePATH, zypper ends up calling this conda version ofrepo2solvinstead of the version shipped by SUSE.The version of
repo2solvshipped by this libsolv package is NOT compiled with theENABLE_RPMMD=1flag, and thus does not supportrpm-mdstyle repositories, which all SUSE repositories are. So when attempting to parse a repository metadata, this version ofrepo2solvjust exits immediately with the error message "rpmmd repo type is not supported", as a hardcoded error case.Other distros ship libsolv compiled with the
ENABLE_RPMMDflag, such as Rocky Linux, and obviously SUSE does.We'd just need to enable that CMake define here, or any of the other CMake defines that transitively set that value to ON (you can search
ENABLE_RPMMDin this file).Which would fix this one issue, but in general if we're going to be replacing the system version of a core tool like part of the distro package manager... it should be compiled in a 100% identical manner to the upstream (which is hard since every distro compiles this slightly differently).
Reproduction:
rootuser, install latestminiforgeconda(last step in the install process)rm -rf /var/cache/zypp/solvzypper refreshExpected Result:
zypper caches are refreshed appropriately
Actual Results:
Every repository is broken with an error like the following:
Other commentary:
This only impacts running conda as
root, since if you install conda as a non-root user you won't be impacting thePATHofrootand won't interfere with thezyppercommands. Running conda asrootis a bad idea in general, but I was and that's how I found this.All forms of conda are pretty intrusive to the
PATH, which is pretty annoying. A very basic default conda env ships its own copies oflibsolv,zlib,xz,lz,sqlite3, etc etc. Many things where I'd be expecting to be running my distro's installed copy, instead I'm running the conda-forge versions because conda put itself first on myPATH. This really seems like a bad practice to me ... for many security / update / stability reasons. But perhaps that's a topic for the main conda-forge area and not here. I've worked around this by writing a custom shell integration script that puts conda after the default PATH entries, so my distro copies get called first instead of conda's, which I'm sure will break something in conda one day when there's a version mismatch.Installed packages
Environment info
The text was updated successfully, but these errors were encountered: