Re: Self-contained Guix tarball

[Ricardo Wurmus]

Pjotr Prins writes:

> On Tue, Apr 21, 2015 at 10:11:29AM +0200, Ludovic Courtès 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 restrict
  );
  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 = old.id and reference = 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