From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#32245: Guix does not search sources locally by hash Date: Mon, 23 Jul 2018 16:50:49 +0200 Message-ID: <87lga2ovjq.fsf@gnu.org> References: <20180722115607.1eea6917@alma-ubu> <877elmuyxh.fsf@gnu.org> <20180723115053.67423d42@alma-ubu> 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]:46223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fhcBx-00059m-KL for bug-guix@gnu.org; Mon, 23 Jul 2018 10:52:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fhcBu-0005hI-JF for bug-guix@gnu.org; Mon, 23 Jul 2018 10:52:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49206) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fhcBu-0005h6-FK for bug-guix@gnu.org; Mon, 23 Jul 2018 10:52:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fhcBu-0005rg-5S for bug-guix@gnu.org; Mon, 23 Jul 2018 10:52:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20180723115053.67423d42@alma-ubu> ("=?UTF-8?Q?Bj=C3=B6rn_?= =?UTF-8?Q?H=C3=B6fling?="'s message of "Mon, 23 Jul 2018 11:50:53 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: =?UTF-8?Q?Bj=C3=B6rn_?= =?UTF-8?Q?H=C3=B6fling?= Cc: 32245@debbugs.gnu.org Bj=C3=B6rn H=C3=B6fling skribis: > On Mon, 23 Jul 2018 10:41:14 +0200 > ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > >> Hi, >>=20 >> Bj=C3=B6rn H=C3=B6fling skribis: >>=20 >> > $> ./pre-inst-env guix build java-eclipse >> > [..] >> > @ >> > build-started /gnu/store/lqfw971srfifgql68ibdgh58vi4d8fq3-java-eclipse= -oxygen-3a-linux-gtk-x86_64.tar.gz.drv >> > - >> > x86_64-linux /var/log/guix/drvs/lq//fw971srfifgql68ibdgh58vi4d8fq3-jav= a-eclipse-oxygen-3a-linux-gtk-x86_64.tar.gz.drv.bz2 >>=20 >> [...] >>=20 >> > But it does NOT search locally. Because I already have: >> > >> > guix >> > hash /gnu/store/56h6snwcawpzk6rhcwgk442wsx6k86q2-eclipse-java-oxygen-3= a-linux-gtk-x86_64.tar.gz >> > 0m7y7jfm059w01x9j5b5qkinjjmhkyygpjabhjf19fg2smxmwcim >>=20 >> It does, but the file name matters. In this case what you have is >> =E2=80=9Ceclipse-java-=E2=80=A6=E2=80=9D but you=E2=80=99re trying to bu= ild =E2=80=9Cjava-eclipse-=E2=80=A6=E2=80=9D. >>=20 >> So you first need to add the file to the store under its expected >> name. You can do that for instance with: >>=20 >> guix download file://=E2=80=A6/java-eclipse-=E2=80=A6 >>=20 >> HTH! > > Not sure yet. I havent't tried it yet, but I'm sure your solution > helps with the specific problem here. (Also updating the URL helps even > better :-)) > > What I feel strange here is: > > * When the file is already on the local disk, it has to match a certain > file name criteria. Quite hard criteria. > * But when asking outside repositories over the network, we just "take > anything that has the hashsum". > > Is that wanted behaviour?=20 It=E2=80=99s not optimal, as you pointed out. But it=E2=80=99s not impleme= nted in these terms. The =E2=80=98add-to-store=E2=80=99 RPC returns a file name that=E2= =80=99s a function of the content and the file name. So the way =E2=80=98add-to-store=E2=80=99 w= orks is: 1. compute store file name =3D g(content, filename) (See =E2=80=98fixed-output-path=E2=80=99 in (guix store).) 2. if store file name exists, return it, else create it. Since /var/guix/db/db.sqlite contains the content hash of each store item, we could in theory perform a lookup by hash. To do that we=E2=80=99d= need to add a new RPC and use it in the correct places. It=E2=80=99d be a nice addition. Ludo=E2=80=99.