guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rav1e AV1 encoder


From: Leo Famulari
Subject: Re: rav1e AV1 encoder
Date: Thu, 27 Feb 2020 12:16:02 -0500

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]