Re: Policy to remove obsolete packages

[zimoun <zimon.toutoune@gmail.com>]

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