Hi, I understand but I am not sure to see the points and/or advantages about a policy.
>From my opinion, obsolete package is not well-defined and define cleanly what an obsolete package is will be bikeshedding. :-) And I think that deprecated should come from upstream. However, a popcon of the downloaded substitutes should provide which packages are "important" and which are less; to have a better "priority list"---if needed. To me, all the QA dance of the "classic" distros come from two key points: missing the rollback and the dependency hell. Because it is hard to rollback if the update/upgrade fails, the user must be sure that nothing will break. Since Guix fixes these two points by design, it does not need a strong QA, I guess. But, I do agree with you that it should not be possible that `guix pull [options]' then `guix build <package>' fail. Never. :-) And maybe the "CI" should have a mechanism such that: pull from branch-unstable, refresh and eval then automatically push to branch-stable if ok, otherwise blame the committer who will manually fix and will push again to branch-unstable. The regular user can add the both branches with the channel mechanism and they will be more sure that `guix pull --commit=' will always work and obtain the last half baked cutting edge stuffs too. And I also do agree that it is hard to find the information what it went wrong. For example, recently I was not able to find what breaks clang@3.5. Well, talk does not cook the rice. :-) (I mean not sure my words are relevant) All the best, simon
