On Fri, Sep 6, 2024 at 4:56 PM Andy Tai <a...@atai.org> wrote: > > Maybe this can be generalized for packages with lots of dependencies, > say for any package A with 300 (or 1000) dependencies, when upgrading > to a new version, add that as A-next so existing A is not touched. > Then A-next can be added without any dependencies, and Guix QA just > needs to check if A-next builds. Then people working on any package > depending on A can move that package to depending on A-next later > independently. This avoid triggering world rebuilds. And A's > dependents migrate at their own flow.
Does the manual upgrade of dependent packages happen in practice outside of receiving an error due to an unsatisfied minimum version? For example, `fmt-9` (the default) has 1812 dependent packages whereas `fmt-10` and 'fmt-11' have none even though the former was added in June 2023. It would be handy to automate the dependency upgrade process when a new package version can be built with a new library version. Likewise, automated, bulk migrations of dependent packages when adding a new library version. An example of the former: when upgrading mariadb and after a successful build, `guix` could be requested to upgrade and build with `fmt-11`, then on failure upgrade and build with `fmt-10`, then on failure leave the input unchanged as `fmt-9`. When upgrading the library itself, for example switching the default `fmt` from `fmt-9` to `fmt-10`, it is almost certain that many packages will break even after the long delay for those dependent packages to be upgraded. I believe this to be a major contributor to the number of broken builds on the master branch, and automating piecewise upgrades should reduce this problem and ease the burden on the contributor. As I understand, there would be cases where multiple packages need to be upgraded together, in particular when propagating inputs. This works today when we upgrade a common default version but we could see an increase in package conflicts as dependencies diverge. It would be necessary, or at least very helpful, to couple the package versions together (ordered by precedence) alongside the package definitions. Greg