Here’s what I don’t understand. Not every package can work with every other version of another package. So there is a constraint network between packages. How do you find a consistent set of versions that allows everything to work together? How do you avoid breaking this when you update one package?
Yes, those constraints exists, and they sometimes, but seldom, cause some serious effort to handle. Especially for rolling-release distributions like Gentoo. But overall it is not a big problem as most packages provide backwards compatibility and most of those that do not can be installed in parallel.
And ultimately you may have no choice but to ask the user to decide for one or the other package (version). But in my experience with Gentoo, those situations are rare and do not last long.
You’ve just defined a Linux distribution. A set of packages which work together.
Typically these seem to revolve a desktop environment, and package compatibility starts with the version of glibc.
However there are other Linux distros which focus on other aims. OpenWrt comes to mind as a non-desktop distro. Its purpose is to ship a kernel and a config web interface, and to push that through a build system which emits hardware-specific pre-made image files.
These aims of the distro, and its current version, dictate which packages can/will be provided. If a package breaks with the rest of the distro, the packager must either find a workaround, or have the package considered for a future release, or exclude the package entirely.
For example, I don’t expect Ubuntu to ship headless router images which run with 32M RAM. I don’t expect OpenWrt to package Proton-GE to play games.
TIL there’s a table of contents drop-down in GitHub.
That is reall nice. I would love to steal that for my wiki.
That’s a really good overview of what being a package maintainer entails without going into too much detail. Kudos!
Here’s what I don’t understand. Not every package can work with every other version of another package. So there is a constraint network between packages. How do you find a consistent set of versions that allows everything to work together? How do you avoid breaking this when you update one package?
Yes, those constraints exists, and they sometimes, but seldom, cause some serious effort to handle. Especially for rolling-release distributions like Gentoo. But overall it is not a big problem as most packages provide backwards compatibility and most of those that do not can be installed in parallel.
And ultimately you may have no choice but to ask the user to decide for one or the other package (version). But in my experience with Gentoo, those situations are rare and do not last long.
You’ve just defined a Linux distribution. A set of packages which work together.
Typically these seem to revolve a desktop environment, and package compatibility starts with the version of glibc.
However there are other Linux distros which focus on other aims. OpenWrt comes to mind as a non-desktop distro. Its purpose is to ship a kernel and a config web interface, and to push that through a build system which emits hardware-specific pre-made image files.
These aims of the distro, and its current version, dictate which packages can/will be provided. If a package breaks with the rest of the distro, the packager must either find a workaround, or have the package considered for a future release, or exclude the package entirely.
For example, I don’t expect Ubuntu to ship headless router images which run with 32M RAM. I don’t expect OpenWrt to package Proton-GE to play games.