Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> Not quite. As Ludo mentioned, you can trivially extract out the file
>> list from nar files already (like guix archive -t). So this new service
>> I'm thinking about which stores the nar files, would be able to read the
>> list of files from the nar.
>
> To clarify, you mean the hypothetical new service for file indexing?
> Or did you mean for the Guix Data Service?

This new hypothetical service. The Guix Data Service just knows about
the existence of some nar files, and the hashes, but I'm not thinking of
having it store the contents, hence having another service to do that.

>>> Please correct me if I got it all wrong! :D
>>
>> All great questions, hopefully I've managed to clear things up!
>
> You did, thanks!
>
> Another practical question: what would be the preferred format for the
> database?
>
> SQLite?  Custom binary?  Plain text?

Architecturally, I see this part of the problem as something that's more
flexible as you could export multiple formats.

Ideally, you'd have some data structure optimised for searching, then
maybe some way of looking up attributes of the outputs (like what
package generates them) and files (what's the size).

Maybe sqlite is one to try initially. There's guile-sqlite3 for reading
and writing, and it can contain multiple tables as well as indexes for
fast searching.

> Where would we store this database?  In /var?

Per user is probably most flexible, so in the home directory somewhere.