On Tue, Feb 25, 2020 at 11:14:29PM -0500, Leo Famulari wrote:
> On Tue, Feb 25, 2020 at 01:21:18PM -0800, John Soo wrote:
> > You should be committing packages in topological order but the file
> > order is alphabetical. 

This is at least partially my fault; I suggested that the packages be
sorted alphabetically after a recursive import. It works well for adding
them all in one channel, not so well for adding them piecemeal to Guix.

> > 
> > Good luck, rust is a ton of work.
> 
> Okay, that makes sense.
> 
> I tried to use `guix graph` to learn the shape of the package graph but
> it doesn't work as expected since these packages don't refer to their
> dependencies in the typical way. I thought that using the 'derivation'
> graph type might help but I don't think that I can process it on my
> computer `dot`. It's been going for hours now...

This is because we technically use the package-source of the packages,
not the packages themselves.

> 
> Many of the "new packages" are actually semver-compatible updates to
> existing packages, and these updates often change the list of
> cargo-inputs dependencies.

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.

> 
> Given that, I don't know how to learn the right order of things to
> commit one at a time that will never break the build.
> 

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.

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.

> 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.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted