From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Self-contained Guix tarball Date: Tue, 21 Apr 2015 12:08:39 +0200 Message-ID: References: <873848p5kd.fsf@gnu.org> <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> <87zj61q4su.fsf@gnu.org> <20150421083722.GA16564@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]:58796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkV6o-0006eb-QS for guix-devel@gnu.org; Tue, 21 Apr 2015 06:08:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkV6l-0001NE-JM for guix-devel@gnu.org; Tue, 21 Apr 2015 06:08:50 -0400 Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:43405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkV6l-0001N6-5W for guix-devel@gnu.org; Tue, 21 Apr 2015 06:08:47 -0400 In-Reply-To: <20150421083722.GA16564@thebird.nl> 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 writes: > On Tue, Apr 21, 2015 at 10:11:29AM +0200, Ludovic Court=C3=A8s wrote: >> The important thing is that currently, the DB is authoritative. So it >> cannot be corrupt (that would be equivalent to having lost /gnu/store >> altogether), and thus it cannot be repaired. > > The point really is that it is not so hard to achieve rebuilding the > database. Anyone on this list thinks that should be possible? I am > asking the big systems guys :) You could rebuild the database only if the contents of the /gnu/store directory were authoritative (which they are not). The database only contains four tables and none of the entries are magical: sqlite> .fullschema CREATE TABLE ValidPaths ( id integer primary key autoincrement not null, path text unique not null, hash text not null, registrationTime integer not null, deriver text, narSize integer ); CREATE TABLE Refs ( referrer integer not null, reference integer not null, primary key (referrer, reference), foreign key (referrer) references ValidPaths(id) on delete cascade, foreign key (reference) references ValidPaths(id) on delete restric= t ); CREATE TABLE DerivationOutputs ( drv integer not null, id text not null, -- symbolic output id, usually "out" path text not null, primary key (drv, id), foreign key (drv) references ValidPaths(id) on delete cascade ); CREATE TABLE FailedPaths ( path text primary key not null, time integer not null ); CREATE INDEX IndexReferrer on Refs(referrer); CREATE INDEX IndexReference on Refs(reference); CREATE INDEX IndexDerivationOutputs on DerivationOutputs(path); CREATE TRIGGER DeleteSelfRefs before delete on ValidPaths begin delete from Refs where referrer =3D old.id and reference =3D old.id= ; end; /* No STAT tables available */ To create records in Refs you would obviously need to know the relationship between packages, but you can get that by using Guix and the package modules as a library. Someone daring enough to mess with the store contents (by manually adding, altering or removing stuff) without going through the daemon would also have to take care of manipulating database records in the appropriate manner. I fail to see, however, in what situation this would be desirable to a system administrator. Sysadmins don't expect, for example, to be able to delete files from a system where software is managed with RPM *without* also having to modify the RPM database to avoid problems. If I were to sync /gnu/store/ across different machines with rsync, I'd make sure to keep any additional state by also copying the localstatedir: /var/guix/. But as I said before, I fail to see a good reason to do this. > It may also allow for people creating other store-based tools in time. Guix can be used as a library and with the store monad it is possible to programmatically manipulate the store. I expect this to become even easier once the daemon is rewritten in Scheme (which is bound to result in more reusable parts that could be glued together by adventurous sysadmins). ~~ Ricardo