From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: Re: Package inputs in manifests Date: Sun, 17 Nov 2019 15:11:55 -0800 Message-ID: <20191117231019.GA1008@PhantoNv4ArchGx.localdomain> References: <87mudrxvs8.fsf@ambrevar.xyz> <87mudd59ho.fsf@gnu.org> <877e4glyc3.fsf@ambrevar.xyz> <87ftj1x8fw.fsf@gnu.org> <87mucupz8k.fsf_-_@gnu.org> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:48802) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWTiR-0001Wx-TN for guix-devel@gnu.org; Sun, 17 Nov 2019 18:12:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWTiQ-0004bB-Gj for guix-devel@gnu.org; Sun, 17 Nov 2019 18:12:23 -0500 Content-Disposition: inline In-Reply-To: <87mucupz8k.fsf_-_@gnu.org> 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.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Guix Devel Hi Ludo, Guix, On +2019-11-17 11:35:07 +0100, Ludovic Court=C3=A8s wrote: > Hi Simon! >=20 > zimoun skribis: >=20 > >> Ah, that no. But (guix scripts environment) has > >> =E2=80=98package-environment-inputs=E2=80=99, which does exactly tha= t, and I guess we > >> could expose it and document it. > > > > Maybe I am doing wrong but I get: > > > > $ ./pre-inst-env guix package -p /tmp/guix-dev -m ~/tmp/manif-dep.scm > > > > installing new manifest from '/home/simon/tmp/manif-dep.scm' with 53 = entries > > guix package: error: profile contains conflicting entries for gzip > > guix package: error: first entry: gzip@1.10 > > /gnu/store/py3k9zla9fj3z7430v4crqj5pyrsd3qj-gzip-1.10 > > guix package: error: second entry: gzip@1.10 > > /gnu/store/i2cdl0hvrml8hjdqplqln8didnvxkgp5-gzip-1.10 > > hint: You cannot have two different versions or variants of `gzip' in > > the same profile. > > > > > > where I tweak guix/scripts/environment.scm to export > > `package-environment-inputs' and ~/tmp/manif-dep.scm contains: > > > > (use-modules (guix) > > (guix profiles) > > (guix scripts environment) > > (gnu packages package-management)) > > > > (make-manifest (package-environment-inputs guix)) >=20 > You=E2=80=99re doing it right! It turns out that two different variant= s of > =E2=80=9Cgzip=E2=80=9D appear: one in =E2=80=98%final-inputs=E2=80=99 (= the implicit inputs of > =E2=80=98gnu-build-system=E2=80=99) and another one somewhere else, hen= ce the collision. >=20 > The solution is to pass =E2=80=98--allow-collisions=E2=80=99, which is = what =E2=80=98guix > environment=E2=80=99 does by default precisely for that reason (see com= mit > afd06f605bf88a796acefc7ed598b43879346a6b). >=20 > We could check exactly why we end up with several =E2=80=98gzip=E2=80=99= instances, but > overall I think this kind of thing is hard to avoid for package inputs. >=20 > Thanks, > Ludo=E2=80=99. >=20 Can "collisions" be collisions even if the targets are bit-identical? E.g. find /gnu -name '*gzip'|xargs sha1sum|gxsnip --8<---------------cut here---------------start------------->8--- 3a69ba705f2a8674fe6f0dfbdbf47de95bf72438 /gnu/store/h0c398zan9ibhk4w0c94= 4vp5pwgzkfpd-gzip-1.9/bin/gzip 3a69ba705f2a8674fe6f0dfbdbf47de95bf72438 /gnu/store/q09sy224qnxrp982z4xf= axi19721mjx8-gzip-1.9/bin/gzip c944319913ed9006b819abceda783ceee0985972 /gnu/store/c6z3v1s9ky7h3wsc6da4= 70s35iiciidd-profile/bin/gzip c944319913ed9006b819abceda783ceee0985972 /gnu/store/i2cdl0hvrml8hjdqplql= n8didnvxkgp5-gzip-1.10/bin/gzip c944319913ed9006b819abceda783ceee0985972 /gnu/store/py3k9zla9fj3z7430v4c= rqj5pyrsd3qj-gzip-1.10/bin/gzip --8<---------------cut here---------------end--------------->8--- It seems like it would be possible to automate an item-specific --allow-c= ollisions where the "collision" is really an aliasing? (IOW, why use different names for the same thing, except for local conven= ience abbreviations?) I see the de-duping gc does when it converts to hard links, and wonder th= ere too. What am I missing? RFE: (request for enlightenment :) Exactly how are the /gnu/store prefixes computed? What _exactly_ is/are t= he input(s) that get hashed?? TIA --=20 Regards, Bengt Richter