Hi Ludo, Guix, On +2019-11-17 11:35:07 +0100, Ludovic Courtès wrote: > Hi Simon! > > zimoun <zimon.touto...@gmail.com> skribis: > > >> Ah, that no. But (guix scripts environment) has > >> ‘package-environment-inputs’, which does exactly that, 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)) > > You’re doing it right! It turns out that two different variants of > “gzip” appear: one in ‘%final-inputs’ (the implicit inputs of > ‘gnu-build-system’) and another one somewhere else, hence the collision. > > The solution is to pass ‘--allow-collisions’, which is what ‘guix > environment’ does by default precisely for that reason (see commit > afd06f605bf88a796acefc7ed598b43879346a6b). > > We could check exactly why we end up with several ‘gzip’ instances, but > overall I think this kind of thing is hard to avoid for package inputs. > > Thanks, > Ludo’. >
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/h0c398zan9ibhk4w0c944vp5pwgzkfpd-gzip-1.9/bin/gzip 3a69ba705f2a8674fe6f0dfbdbf47de95bf72438 /gnu/store/q09sy224qnxrp982z4xfaxi19721mjx8-gzip-1.9/bin/gzip c944319913ed9006b819abceda783ceee0985972 /gnu/store/c6z3v1s9ky7h3wsc6da470s35iiciidd-profile/bin/gzip c944319913ed9006b819abceda783ceee0985972 /gnu/store/i2cdl0hvrml8hjdqplqln8didnvxkgp5-gzip-1.10/bin/gzip c944319913ed9006b819abceda783ceee0985972 /gnu/store/py3k9zla9fj3z7430v4crqj5pyrsd3qj-gzip-1.10/bin/gzip --8<---------------cut here---------------end--------------->8--- It seems like it would be possible to automate an item-specific --allow-collisions where the "collision" is really an aliasing? (IOW, why use different names for the same thing, except for local convenience abbreviations?) I see the de-duping gc does when it converts to hard links, and wonder there too. What am I missing? RFE: (request for enlightenment :) Exactly how are the /gnu/store prefixes computed? What _exactly_ is/are the input(s) that get hashed?? TIA -- Regards, Bengt Richter
