On Wed, Jul 20, 2016 at 01:20:26PM +0200, Ricardo Wurmus wrote: > >Tomáš Čech writes: > >> On Tue, Jul 19, 2016 at 04:23:14PM +0200, Ricardo Wurmus wrote: >>> >>>Tomáš Čech writes: >>> >>>> Imagine situation where person A is running some distribution with >>>> Guix package manager on top and has some set of his personal packages >>>> containing additional patches which are not part of Guix GIT. >>>> >>>> He'd like to share the package with person B, running different >>>> distribution with Guix package manager at different revision on top, >>>> with different set of personal packages and alterations. >>>> >>>> I'd like to provide them a way, how to pass from person A to person B >>>> some binary archive in a way that he could understand (and verify) >>>> what he received. If it requries out-of-tree package definitions of >>>> person A, patches, etc, bundle it together. >>> >>>This is already possible with “guix archive --export” and “--import”. >>> ... >>>What’s not so nice about this is that you can end up with binaries in >>>your store that you cannot rebuild yourself (because you never had the >>>sources to begin with). (I wonder if this has implications on software >>>freedom.) >>> >>>~~ Ricardo >>> >> >> Ooops, I answered to Ricardo only... >> >> Yes, you can take exported archive (optionally with it's dependencies >> - --recursive) and add it to the person B's store. That is comparable >> to tarball (and making Guix aware of new items in store). >> >> The thing that you can't rebuild the binaries is exactly my point, >> because person A knows how to build it, but person B does not. Thanks! > >Are you suggesting that package archives and store exports must include >all package expressions (and all supporting code to build them) needed >to reproduce them? The store can hold packages that were built with >different versions of Guix. Does this mean that each version of Guix >that has been used should also be kept in the store? First, I'm not saying that we should do that for every archive, but I think that having a way how to automatically export this information would be great and I see it as a week point for using Guix packages as alternative to Snappy or Flatpak. Now, as long as Guix sources are part of equation and change during the time, you may need to keep more Guix versions. If there is some stable not-changing core, you probably could eliminate the need. >But wait, this goes even further than just versions of Guix. There may >be stuff in the GUIX_PACKAGE_PATH. Are you suggesting that all of this >should become part of package archives? This doesn't sound like tougher problem than the rest - you have separate package definitions. It means just more data to process. (that doesn't mean that problem is easy to solve) >If so: how? 1] I guess I should better explain my position. In the discussion on social media I was explaining why it can't be used now for self-containing packages and what is missing. My goal now on the mailing list is here the discussion itself, to see whether it is possible and whether are people interested in that. 2] I don't know much Guile, maybe there is nice way how to work with Scheme program from Scheme program. If I should implement it, I'd need to strictly "draw line" between package definitions and Guix itself, then I would need to parse package definitions files to identify which parts were used and ship those. Maybe you can get this information during evaluation by some side effect. I don't know Guile enough, really. S_W