unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Hartmut Goebel <h.goebel@crazy-compilers.com>
To: Marius Bakke <marius@gnu.org>, Guix-devel <guix-devel@gnu.org>,
	zimoun <zimon.toutoune@gmail.com>
Subject: Re: Downloader for "wrapped" tarbar?
Date: Sat, 6 Jun 2020 17:29:43 +0200	[thread overview]
Message-ID: <8716b84c-ba1e-2cce-3e14-c289f63a7d2a@crazy-compilers.com> (raw)
In-Reply-To: <87y2p5uufv.fsf@gnu.org>


[-- Attachment #1.1: Type: text/plain, Size: 1400 bytes --]

Am 02.06.20 um 21:41 schrieb Marius Bakke:
> It would be ideal to have an origin method that could extract the
> "inner" tarball, i.e. contents.tar.gz for hex.pm and data.tar.gz in the
> case of RubyGems.  As zimoun mentioned, a good place to start is look at
> how other origin methods are implemented such as url-fetch/tarbomb, etc.

I started implementing into this direction and would like your advice on
the design. I found two options:

1. When implementing some "url-fetch/wrapped" (name tdb), *two* items
will be kept in the store: the "outer" and the "inner" tarball. This is
since "url-fetch" and siblings use the built-in downloader, which AFAIK
always puts the downloaded files into the store.

In this case we need to check the hash of the "outer" tarball, as the
built-in downloader requires a hash to be passed and to match. But then
we can not check the hash of the "outer" tarball. How would this work
with substitutes and download-nar?

2. When implementing some "wrapped-fetch" (name tdb), modeled like
"git-fetch", there is no easy way for the user to verify the hash, as
this is taken from the "inner" tarball. How does this work with
substitutes, download-nar and SWH?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-06 15:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-30  8:39 Downloader for "wrapped" tarbar? Hartmut Goebel
2020-05-30 10:24 ` Ekaitz Zarraga
2020-05-31  8:19   ` Hartmut Goebel
2020-06-01 14:19     ` Ekaitz Zarraga
2020-05-31  8:21 ` Software heritage and " Hartmut Goebel
2020-06-01 14:12   ` zimoun
2020-06-02 19:41 ` Marius Bakke
2020-06-06 15:29   ` Hartmut Goebel [this message]
2020-06-06 17:26     ` zimoun
2020-07-06  7:37 ` Available for testing: hex.pm downloader and rebar3 build-system Hartmut Goebel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8716b84c-ba1e-2cce-3e14-c289f63a7d2a@crazy-compilers.com \
    --to=h.goebel@crazy-compilers.com \
    --cc=guix-devel@gnu.org \
    --cc=marius@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).