HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
openSUSE
libsolv
C2015–2024
openSUSE / libsolv

libsolv

Library for solving packages and reading repositories

6Distinct people
8Mentions
0Explicit recommenders
615GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Library for solving packages and reading repositories

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2015-05-18 10:31:01 UTC to 2024-07-01 19:56:50 UTC.

01232015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202

What Hacker News says

8 sources
> So to me, all that sounds is nifty, but not especially impressive. Any devops team could write something to do the same in a couple of hours. If other distros don't have that, it could simply be because they don't need it. This isn't a complete description of openQA, but an illustrative snapshot. Btw, it looks like Fedora has adopted this tool as well (several years ago, hehe): https://openqa.fedoraproject.org/ And yet there is no one anywhere who claims that Fedora Rawhide is more stable than openSUSE Tumbleweed. This is in part because of a real difference of purpose and outlook; Tumbleweed is somewhat exceptional as a rolling release which explicitly emphasizes stability through automated testing as a value and goal. > > It is possible that other distros are catching up here > This is the crux of your position, though, that all these
Read the rest
other distros are that much more behind openSUSE. You start your reply with "yes and yes", very confident, but now here in the meat of the discussion you say you don't actually know. > I'm not trying to be combative or adversarial here, but it really seems like a lot of assumptions are being made. Sure. I'm not an active contributor to openSUSE or Debian or RHEL, and I'm not currently working on a study of their production pipelines. I'm just trying to give you a clearer picture of some differentiators that I've picked up as a Linux user, developer, and ops professional with the incidental experience I've had with those distros in the past ~20 years. But I think some of these 'assumptions' are pretty fair, e.g., the distro that created and chiefly maintains openQA has a more mature automated testing infrastructure than a distro that only adopted it a few years ago. > My days of installing a distro for fun have been over for a long, long time. Now I only really like Alpine, Devuan if I need something chunkier. I appreciate the suggestions and conversation though, thanks! You don't need to install (or use) openSUSE to play with OBS. Just make a free account on build.opensuse.org and start building packages for any DEB-based, RPM-based, or PKGBUILD-based distro (as well as container images incl. for Docker, AppImage, Snap, and Flatpak). No Alpine/apk support yet, sadly. Idk whether Devuan is supported as a base distro or not, but there are some repositories intended for use with Devuan hosted on build.opensuse.org, e.g.: https://build.opensuse.org/project/show/home:bgstack15 > Well, I never doubted that was possible. I'm just skeptical OpenSuse's testing setup is/has leading/led to a system that is more stable or whatever other supposed advantages it has over say Debian and Red Hat. The only way you can really compare the stability of two distros is by actually running them. What I can offer you short of that experiential knowledge is that openSUSE has a sophisticated, mature testing infrastructure of which major components have been adopted by the other distros you cite as examples. You will be hard pressed to find someone who can compare the testing infrastructure of even just two distros in great detail and totally current. This guy probably can, he's a major NixOS/nixpkgs contributor, a Fedora developer, and an Alpine contributor: https://github.com/fabaff . I can't personally think of anyone else, but I'm sure there are some. I can tell you that still fairly recently, one Debian developer gave a talk about the Open Build Service with the subtitle 'fix the mess': https://www.youtube.com/watch?v=Nh0FoS_J_Gs > Is that cruft not just project preferences, of which each distro has it's own version? Yes? But preferences can be literally anything with widely varying impacts on social and technical processes... so to say 'everyone has them' doesn't really say anything at all. Anyway, about the actual package managers I can be much more concrete because I've used them all much more recently. > So, what makes the openSUSE package manager so much better than apk, apt or xbps? Like I said, I won't speak to xbps because I've not used it. Additionally, this comes with the caveat that you may prefer package managers that make different tradeoffs than zypper and dnf do. But here are the things that openSUSE's package manager (and nowadays also Fedora's) get really right imo that apk and apt are lagging on. This means that resolving dependencies in a way that is guaranteed to be both correct and complete requires is hard (indeed, it's NP-hard). Dependency managers that take this seriously employ SAT solvers, openSUSE's now lives in this library: https://github.com/openSUSE/libsolv. apt lagged behind zypper in this area for many, many years, and just finally got a SAT solver for dependency resolution a couple months ago: https://blog.jak-linux.org/2024/05/14/solver3/ . Apk doesn't have a backtracking dependency solver and thus will sometimes fail to identify possible solutions to dependency resolution problems, even when they exist. But for that, it gets to be fast. I believe pacman and xbps also make that same tradeoff (completeness for speed). Apt has similarly lagged in establishing a modern command-line interface. Zypper provided a modern, unified subcommand interface for managing all packages and repositories when it came out nearly two decades ago, whereas apt has only offered a modern subcommand interface for less than a year ( https://9to5linux.com/ubuntu-24-10-and-debian-13-trixie-to-f... ), and last I used it (within a year or two) it also still lacked facilities for key management (apt-key was deprecated but there is no integrated replacement). APT is making some very nice advances, but they're still playing catch-up. The single thing I miss the most with APT, though, is entirely missing, and it's the notion of 'vendor'. openSUSE's package manager introduced me to the concept of 'vendor stickiness' (https://en.opensuse.org/SDB:Vendor_change_update), which allows you to upgrade without changing who is providing what package for you in a natural way. (This idea has also since been adopted by Fedora in their `dnf` package manager, as well.) Zypper's facilities for creating a hierarchy of repositories, prioritizing them, and marking some equivalent to others with respect to 'vendor', are just way more flexible and powerful than anything available in APT. > I mean, Debian as a system has a standard for its packages, standardizing what they felt they needed to, and all packages adhere to that and the system has been working well From a packager's perspective, the tooling situation for openSUSE is also way more uniform than for Debian or downstream distros, which can make it easier to get your head around. Even a small amount of packaging experience for Debian is enough to reveal a marked enough difference here to justify a preference for some other distro. > possibly longer than suse has even existed. Debian is something like 6 months older than SUSE. SUSE, like Debian, is one of the oldest surviving Linux distributions.
In Aeon: OpenSUSE for Lazy Developers
prefix-dev/pixi is a successor to Mamba and Conda which wraps libsolv like dnf. https://github.com/prefix-dev/pixi OpenSUSE/libsolv: https://github.com/openSUSE/libsolv OpenSUSE/zypper may have wrapped or may still wrap libsolv? TIL libsolv also supports arch .apk and .deb; there's a deb2solv utility to create libsolv .solv files: https://github.com/openSUSE/libsolv/blob/master/tools/deb2so... "[mamba-org/rattler:] A new memory-safe SAT solver for package management in Rust (port of libsolv)" (2024) https://prefix.dev/blog/the_new_rattler_resolver https://news.ycombinator.com/item?id=37101862 Pixi is integrating uv: https://github.com/astral-sh/uv/issues/1572#issuecomment-194... astral-sh/uv [1] solves versions with PubGrub [2], which was written for Dart: [1] https://github.com/astral-sh/uv [2] https://github.com/pubgrub-rs/pubgrub uv's
Read the rest
benchmarks are run with hyperfine, a CLI benchmarking tool: https://github.com/sharkdp/hyperfine astral-sh/rye was mitsuhiko/rye, and rye wraps uv with "fallback to unearth [resolvelib] and pip-tools": https://github.com/astral-sh/rye https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/ So, TIL it looks like rye for python and pixi for conda (python, r, rust, go,) are the latest tools for python packaging, not apt packaging. fpm is one way to create deb packages from python virtualenvs for install with the new APT solver, which resulted in this research.
In The new APT 3.0 solver
(disclaimer: SUSE employee and user) I get the impression that people using Debian and their derivatives seem to live under a rock regarding other distributions. I would trust zypper dup hundred times over apt-get dist-upgrade. This gets amplified by the fact that openSUSE Tumbleweed (rolling distro), is much better auto-tested before being published every week, than my experience with sid was (tested by their end-users). Today's Redhat dnf package manager is based on SUSE's dependency solver (https://github.com/openSUSE/libsolv), and both package managers provide a very nice user experience. People seem to be still confused about SUSE "using YaST". YaST is just a front-end powered by libzypp (https://github.com/openSUSE/libzypp), like zypper is.
In Suse is once again an independent company
Former libzypp/zypper developer here. It was not mentioned in the post that dnf is based on the openSUSE dependency SAT solver (libsolv) that was created by Michael Schroeder years ago and that powers libzypp and zypper since openSUSE 11.0. The dnf developers built a thin layer on top of it, called hawkey, and then build dnf in python on top of hawkey. One of the biggest innovations of libsolv is not only the SAT based solver but also the .solv format which allows to store package metadata for big amounts of packages in an efficient way and operate the solver directly on it. https://github.com/openSUSE/libsolv
In Yum is dead, long live DNF

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.