Hi simon, On Thu, 7 Feb 2019 13:40:53 +0100 zimoun wrote: > 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. I really wouldn't take that "Policy" too formal: It is more like that: There are packages that are just broken and nobody cares. But nobody removed them from Guix, because everybody was unsure about it. Now we agreed on that when a package is broken for more than 6 months we should announce it on dev-list and if then nobody takes action, we remove it. It is more like "community consensus" that it is very OK to remove these packages. CI is another related topic we are working on. In theory, a commit should break nothing. Or at least the commiter should get a message back of what exactly they broke. > 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. Sometimes it magically helps to just write a bug-report with the correct error-message and/or link to hydra.gnu.org's failure. I noticed in the past that a good, concise bug-report gets attention to the right people to fix it :-) Björn