Am Dienstag, den 01.06.2021, 10:59 +0200 schrieb Adriano Peluso: > Il giorno mar, 01/06/2021 alle 08.24 +0200, Leo Prikler ha scritto: > > > A sexp-pack would represent the most simple build instructions to > > > build a package on its own. Now, of course the current guix- > > > builders solve that too. But, what I am proposing is to split out > > > the actual build step into a package definition, so as to present > > > something simpler to Guix. > > I don't think this would be simpler to Guix, you'd just create even > > more packages, that actually aren't usable. > > The output could be a collection of .tar.gz files distributed through > ipfs, bittorrent, syncthing or rsync > > Not necessarily packages in the way Guix intends them > > I understand there's already some work going on to reproduce tarballs > in a format convenient to Guix (maybe with proper hashes and metadata > ?) for when they get erased by distributors Well, ideally Guix would have have ipfs-fetch, bittorrent-fetch etc. as methods or fallbacks, but this doesn't solve the problem that's posed here. You can't just pull the complete source closure of e.g. Fractal over the ether and pretend it's just one package. We already drop all vendored dependencies from tarballs, that aren't created by Rust et al., this does the exact opposite.
Regards, Leo
