On Thu, Feb 27, 2020 at 12:16:02PM -0500, Leo Famulari wrote:
> 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?
> 

Just search for snippet in (gnu packages crates-io). rust-bzip2-sys was
particularly bad and basically needed to be replaced, but expat-sys,
jemalloc-sys, libgit2-sys, libssh2-sys etc all bundle the library.

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

There are a couple of those in rust-land too.



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