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 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 ?


Reply via email to