Hi Oleg, On 2026-07-01 at 09:44+01:00, Sharlatan Hellseher wrote: > I think I've faced the same situation a while ago; there is no common > practice or documented process on how to refresh a packages in bulk (or > I'm aware of). > > It become a crucial to have such a policy or mechanics - migration > to Python 3.12 just revealed that fact that Guix accumulates artifacts: > never updated, dated, not compatible with higher versions packages and > package version variants just make situation even worse.
Version variants bothers me a lot to, and to me most of them are born out of the lack of (efficient use of) computing resources. On 2026-07-01 at 09:44+01:00, Sharlatan Hellseher wrote: > Splitting package collection looks like an heavy duty task especially to > keep it stable for a long run. The proposed process tries to avoid rebuilding a dependent when multiple dependencies are due for update within a short time interval. That being said, the splitting task is indeed going to be heavy duty as the (49, 347, 1793) packages in the core 3 rings span in 4, 82 and 216 (!) modules, respectively. I wonder if it's okay to duplicate their entire copyright headers in the new channels instead. On 2026-07-01 at 09:44+01:00, Sharlatan Hellseher wrote: > Some practical solution I found 2y ago is to have graph stats calculated > first, count all visible packages with basic metrics per each package > [1], [2]: [...] > > - all-inputs-count :: sum of native-inputs, inputs and propagated-inputs > - dependents-count :: output of "guix refresh --list-dependent" > - affect-ratio :: (round (* (/ dependents-count packages-count) 100) 5); > e.g. 6.57797 is quite high impact or 60.93001 > more than a 1/2 of all. > > I've never run it for the whole collection but only for some portion of > it during go-team, python-team and science-team refresh sprint, and keep > produced stats files for the farther calculation [3], [4], [5]. With 30949/33138 packages with at most 300 dependents, for a rough figure 93% packages has <1% affect ratio. The scripts I'm using are here BTW: https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00188.html On 2026-07-01 at 09:44+01:00, Sharlatan Hellseher wrote: > From [4]: > > Tiers manifest files are to help planing packages update in advance. > > 1-3 :: Packages with high impact ratio and mainly updated on the > python-team branch. > > 4 :: Packages with high number of inputs, building which ensure the > health of large portion of the graph. > > 5 :: All leaf packages which safe to update directly on master branch. > > Having stats aside would help to plan what to update where (and produce > dynamic manifest files), the only difficulties I currently facing is > amount of time to calculate it; for the python-team packages it takes > about 1-1.5h for 4000 packages. > > If we may have this built-in to Guix it would be supper helpful ^.^ e.g. > > guix refresh --show-stats I think most of the time is spent on networking, which could be cached. As for the update candidates, Repology already has the list of our outdated packages and their (supposedly) latest version: https://repology.org/projects/?inrepo=gnuguix&outdated=1 The graph calculation in split.py (which reconstructs transitive dependencies and dependents for all packages) only takes around 5 minutes on my machine. Best wishes, Phong
signature.asc
Description: PGP signature
