Am Dienstag, den 01.06.2021, 12:52 +0200 schrieb Adriano Peluso: > Il giorno mar, 01/06/2021 alle 11.11 +0200, Leo Prikler ha scritto: > > > 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. > > Probably the Fractal package will depend on some others, so it's > gonna be a collection 🤷️ > > Doesn't that happen already for traditional tarballs ? We don't stuff tarball collections into packages. We stuff inputs into packages and one input equals one tarball.
> > We already drop all > > vendored dependencies from tarballs, that aren't created by Rust et > > al., this does the exact opposite. > > I'm not sure I understand > > This does the opposite ? > > How so ? Let's assume we form this sexp-pack and use it as input to some package. What happens? Regards, Leo
