On Tue, 5 Feb 2019 00:47:42 +0100
zimoun <zimon.toutoune@gmail.com> wrote:

> To me the question is more about how to automatically detect that a
> patch breaks another package than a policy to remove a broken package.
> 
> I mean if we are able to automatically detect 6 months later that a
> package is broken, why are we not able to report the failure earlier?
> And if it is not automatic, this means that someone reports  the
> failure by hand, so somehow this patch is important to them and then
> why remove it?

1. To check that A has dependency B and upgrading A breaks B:

We discussed on Guix-Days on how to automate this and there are some
ideas around, but nothing fully-automated is there yet.

Current state:

When updating A, developers can call "guix refresh -l" and see which
B's are affected and can build them too (if not too much).

Also, the build farms are evaluating them eventually and you can
manually look up if something went wrong (though this is tedious and
errors can slip through).

So, no, there currently is no automatic notification/report. Thus,
someone does this by hand. If it is a package of interest to that
person, they at least write a bug report or have ideas on how to fix it.

It could also be a person that has no direct interest or is not an
expert for that package. For example, I sometimes just go through the
errors of the latest evaluations (https://hydra.gnu.org/evals) and see
if anything can be done.

Then I notice that it probably broke because of some qt-update, nobody
cared, nobody still cares, I'm looking on how to fix it, upstream has
no patches since months/years, project was forked, totally restructured
etc.

If then after a post to the list still nobody shouts up, I find it
reasonable to remove the package. Sure the period of 6 months is just a
rough notion.

Björn