Re: Guarantee of no broken dependencies?

[Ignas Lapėnas]

If a borked dependency will be uploaded, every build that depends on such a
dependency will change hash, and therefore will have to be rebuilt. The build
process also includes testing.

Since all updates are atomic, if any one package fails nothing gets updated, and
you can continue using your stable Guix system.

There is a possibility that an update to a common dependecy will break some of
the child packages (API changes). Unless you are affected by such a child
package your update will gladly use the breaking dependency.

If you need to find out if a child package still works after an update, then you
have to build it and test it with a new package. Normal development workflow
continues.

Peter Polidoro <peter@polidoro.io> writes:

> For every commit to the Guix master branch, is there a guarantee that there 
> are no packages with broken dependencies?
>
> I have not experienced packages with broken dependencies, so I am curious how
> that is checked. In theory, someone could make a commit that accidentally 
> breaks
> other packages correct? Aren’t most inputs just found by name, not name and
> version or hash?
>
> Do packages not get broken, though, because right before every commit the
> updated package is built, along with every package that depends on the updated
> package? Is that enough to make sure all dependencies are fine? There are no
> race conditions with other people making updates at the same time?
>
> How can we do such a consistency check or have such a guarantee when we use
> multiple channels? Does we just rebuild every package in every non-Guix 
> channel
> every time we update Guix to find out what breaks?