Re: Self-contained Guix tarball

[Pjotr Prins]

> What do you mean by ???rebuild should not be necessary????  If you
> remove files from the store manually?

When you administrate a large amount of servers things can go wrong
due to system failures, failed backup recoveries, hacking attempts and
adminstrators trying to be clever ;). Murphy's law dictates that the
store and the sqlitedb meta information will go out of sync. For
production setups it is necessary to be able to recover from backups,
but as an intermediate recovery step it would be really nice if Guix
could recover its meta information from an existing store - assuming
only the DB is corrupt (google for sqlite corrupted databases). It is
especially nice when your backups are out of sync too.

guix archive looks good, but for speedy deployment it can happen an 
adminstrator would have a simple use case of:

- Copying 2 stores to 1 machine
- Rebuild database

to do it quick and dirty. Since all software packages are isolated
this would make a really good use case even if (with some trouble) you
could use guix archive for that. I prefer quick and dirty.

I am not pushing for this functionality directly, but I would
certainly like to have it when I need it :)

Maybe I am being pathetic (a lot of people won't appreciate the
problem), but under time pressure which huge deployments - this is
what is going to be wanted.

On Mon, Apr 20, 2015 at 10:49:05PM +0200, Ludovic Courtès wrote:
> address@hidden (Taylan Ulrich "Bay??rl??/Kammer") skribis:
> 
> > Would it be possible to bundle meta-data files together with store
> > items?
> >
> > I guess one could in principle make each store item a directory with any
> > number of meta-data files plus the actual content of the store item (a
> > file or directory), but I suppose it would be too big an overhaul of the
> > design to make this worthwhile.
> 
> I suspect this would make GC inefficient (lots of disk seeks to
> determine references/referrers compared to queries of the SQLite
> database.)

Yes, Nix switched to using sqlitedb because of the GC. It is also
useful to search current versions of installed packages quickly. Even
so, I think it should be viewed as an index. The state of the machine
is what is *sitting* in the store. That would be the correct design.

Meta information can go out of sync. Therefore we should not assume
they are in sync.

And it is simple to achieve. Just allow for database rebuilds.

> Another (opposite :-)) option is to make /gnu/store a read-only bind
> mount on GuixSD.  Commit 3392ce5 does that.  This will prevent
> accidental modifications of the store.

That is a good solution for end-users. Not for administrators. So
adminstrators will circumvent it.

Remember Guix is a hackable system. That is true for the store too.

Pj.