From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: Package file indexing Date: Fri, 10 Jan 2020 13:35:23 +0100 Message-ID: <87h813wktw.fsf@ambrevar.xyz> References: <20190314204941.GA21065@jasmine.lan> <87mulx9kuv.fsf@nckx> <87zhpx846u.fsf@ambrevar.xyz> <87bm21y2s2.fsf_-_@gnu.org> <87imw7cpe7.fsf@bababa.i-did-not-set--mail-host-address--so-tickle-me> <87pnqdhkpf.fsf@gnu.org> <87imlt3hr2.fsf@ambrevar.xyz> <87png11xgi.fsf@cbaines.net> <87tv5cpypp.fsf@gnu.org> <874kx4anch.fsf@ambrevar.xyz> <87blrc1sos.fsf@cbaines.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58637) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iptVg-0008Pf-9x for guix-devel@gnu.org; Fri, 10 Jan 2020 07:35:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iptVe-0006ot-Vx for guix-devel@gnu.org; Fri, 10 Jan 2020 07:35:28 -0500 In-Reply-To: <87blrc1sos.fsf@cbaines.net> 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-mx.org@gnu.org Sender: "Guix-devel" To: Christopher Baines Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christopher Baines writes: > So, to elaborate a bit more on the architecture I've had in mind for > dealing with the actual nars=E2=80=A6 > > I see the scope of the Guix Data Service extending as far as what nars > are available for outputs, and what outputs are associated with each > revision, but I don't think it should store the actual nar files. > > What you could have is another service, which subscribes to the Guix > Data Service to find out about new revisions and nars (from build > servers). When this new service finds out about Guix revisions, it would > ask this Guix Data Service for all the outputs, and store this away in a > database. When it finds out about nars, it would download them, and > maybe extract out the list of files. > > I think this setup would allow this new service to construct a file > containing information about all files in all the outputs for a > revision, which it has nars available for. This file could then be > downloaded, and searched through when you want to find which output > contains a file. Tell me if I understood you correctly: in this scenario we would modify the Guix derivation process to store the file list in the nars. Is this co= rrect? Question about the Guix Data Service: I suppose that the information about = the outputs of a given revision is built incrementally, i.e. as they get published by the build farm. Is this correct? If so, then the file index service needs to update the database incrementally as well. So we need some entry point to fetch the information delta between now and the last time we fetch the information. Please correct me if I got it all wrong! :D =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl4Yb4sACgkQm9z0l6S7 zH9Tpgf8DUIv7nX6xFOZ++tg09k6qna1WkyLWYr8sYh/gaZC9KigbO6hnl4rKBKl wm6NbJPqtfm2UISYOrIYJIWr0ybtq/+QxLCG7aUSehZRa1IewmQq4Cwrs0A12LaG KticDTA++5TbE6/c6YRJl7Uu3X7FoyTY3DMUSiP4rhGHUw5CPtltr/MY/hkVv1OH qwGQBqrf+49Yx+Flc6NwnwgZWuJENU9jypkA4Rz0U8javKCou8/QgRiaZigV5NHd e0fueAvUUsWGPSCsheHXD4gCq3JIETbFC5YeG98bzow5q3vDJXIxQ4yisr89OORB nRb4WESvpVFQ3c9pb8z9QGMYx27nSg== =KpXe -----END PGP SIGNATURE----- --=-=-=--