On Wed, Feb 26, 2020 at 09:09:05AM +0200, Efraim Flashner wrote:
> Short of resorting them I'd start with ones that have no dependencies,
> just rely on rust-quote & friends or are older versions. Some packages,
> like rust-futures-*, should be updated as a group since they all expect
> to be the same version.

Okay.

> The only real builds that we care about are the packages in rust-apps
> and librsvg-next (and librsvg-next is less important). And of course
> that we don't reference packages that don't exist yet.

Right, but keeping Guix building without "undefined variable" warnings
is what I'm worried about here.

> The ones that I spend the most amount of time reviewing are the ones
> that end in -sys or otherwise reference system libraries. Sometimes more
> effort is needed to unbundle libraries. In general anything that wants
> rust-{cc,cmake,pkg-config} is suspect.

Hm... you're saying they sometimes bundle C / C++ language libraries?

> > Would we have the same issue with updating this kind of large package
> > tree automatically with `guix refresh` and committing the changes one at
> > a time?
> > 
> 
> Sometimes. We do have other upgrades where we go and do a bunch at once,
> where they rely on each other and expect specific versions. The first
> thing I can think of is certbot.

Certbot is special in the sense that certbot and python-acme are
actually developed in the same Git repo but are split up for PyPi
distribution in the hope that other projects will build on python-acme.