From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Policy to remove obsolete packages Date: Thu, 7 Feb 2019 13:40:53 +0100 Message-ID: References: <20190204100318.208254da@alma-ubu> <20190204180635.GB8736@jurong> <20190204221804.GA8806@jasmine.lan> <20190205112443.41fd031b@alma-ubu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:40543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grizL-0007uW-Ig for guix-devel@gnu.org; Thu, 07 Feb 2019 07:41:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1grizK-0003hd-SH for guix-devel@gnu.org; Thu, 07 Feb 2019 07:41:07 -0500 Received: from mail-qt1-x82d.google.com ([2607:f8b0:4864:20::82d]:32771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1grizK-0003gv-L2 for guix-devel@gnu.org; Thu, 07 Feb 2019 07:41:06 -0500 Received: by mail-qt1-x82d.google.com with SMTP id l11so11744438qtp.0 for ; Thu, 07 Feb 2019 04:41:06 -0800 (PST) In-Reply-To: <20190205112443.41fd031b@alma-ubu> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?UTF-8?B?QmrDtnJuIEjDtmZsaW5n?= Cc: guix-devel 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 ' 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