From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Self-contained Guix tarball Date: Tue, 21 Apr 2015 14:16:58 +0200 Message-ID: <87y4llllqd.fsf@gnu.org> References: <20150410131420.GB24509@thebird.nl> <87a8ydt8k8.fsf_-_@gnu.org> <871tjlxen6.fsf@gnu.org> <20150416053355.GD21015@thebird.nl> <87k2x9b061.fsf@gnu.org> <87h9sci6n7.fsf@taylan.uni.cx> <87pp6ywmny.fsf@inria.fr> <20150421070357.GB15795@thebird.nl> <20150421071913.GA15969@thebird.nl> <87lhhlq4gk.fsf@gnu.org> <20150421084438.GC16564@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkX6t-0000xc-OB for guix-devel@gnu.org; Tue, 21 Apr 2015 08:17:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkX6q-0000pq-Fn for guix-devel@gnu.org; Tue, 21 Apr 2015 08:17:03 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkX6q-0000pm-CD for guix-devel@gnu.org; Tue, 21 Apr 2015 08:17:00 -0400 In-Reply-To: <20150421084438.GC16564@thebird.nl> (Pjotr Prins's message of "Tue, 21 Apr 2015 10:44:38 +0200") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins Cc: guix-devel@gnu.org Pjotr Prins skribis: > True if you ignore my message about the state being in two places and > the database can go out of sync/be corrupt. > > Rebuilding the database from a store layout would take many of my > concerns away. What do we have against it? It=E2=80=99s not about being for or against. :-) The important state is in the database. So if something is to be rebuilt, it=E2=80=99s the store, not the database. The database cannot be =E2=80=9Cguessed=E2=80=9D from the set of files foun= d under /gnu/store because not all of them are valid. This is the current design, and it=E2=80=99s consistent. One could come up= with a different design, like Taylan suggested, but we have yet to see what could be better than this. Ludo=E2=80=99.