unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: EuAndreh <eu@euandre.org>
To: Leo Famulari <leo@famulari.name>
Cc: help-guix@gnu.org
Subject: Re: Can't serve a custom channel on a HTTPS repository
Date: Wed, 15 Sep 2021 14:00:59 -0300	[thread overview]
Message-ID: <163172525988.1171990.1918429373113497775@localhost> (raw)
In-Reply-To: <162982163567.793927.6624373973993891167@localhost>

Final conclusion:

libgit does support bare repositories served via HTTP, but only when using Git's
"Smart HTTP", but not the "Dumb HTTP" [0].

Take Guix's channel served on Savannah:

    $ curl -I https://git.savannah.gnu.org/git/guix.git/info/refs
    HTTP/1.1 200 OK
    Content-Type: text/plain

    $ curl -I https://git.savannah.gnu.org/git/guix.git/info/refs?service=git-upload-pack
    HTTP/1.1 200 OK
    Content-Type: application/x-git-upload-pack-advertisement

In this case, Savannah is honouring Git's query params, and speaking the
"Smart HTTP" protocol.

The problem came when I tried serving a bare Git repository over HTTP using the
"Dumb HTTP" protocol, and that libgit doesn't implement [1]:

    $ curl -I https://euandreh.xyz/package-repository.git/info/refs
    HTTP/2 200
    content-type: text/plain; charset=UTF-8

    $ curl -I https://euandreh.xyz/package-repository.git/info/refs?service=git-upload-pack
    HTTP/2 200
    content-type: text/plain; charset=UTF-8

[0]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols
[1]: https://github.com/libgit2/libgit2/issues/4652#issuecomment-390903142

---

So my suggestion is that Guix understands how to fetch from channels that are
just tarballs.  Right now channels are married to Git, and specifically,
libgit's reimplementation of Git.  This is limiting for people who:

1) want to have bare Git repositories served via HTTP, but using only the 
   "Dumb protocol";
2) want to have Guix channels on things other than Git, like Mercurial, Fossil,
   BitKeeper, etc.;
3) want to distribute only the tarball of the channel, and not the repository
   where the code of the channel lives.

I see Guix channels understanding tarballs as a solution to the above.  One
could argue that other DVCS would be treated as second class, since no
authentication or caching would be done, but I find this reasonable, and also
decoupled from the choices of the channel provider.  As long as they can produce
a tarball with Guile files, iit works.  This is a much lower bar to creating and
maintaining Guix channels.


  reply	other threads:[~2021-09-15 17:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 17:36 Can't serve a custom channel on a HTTPS repository EuAndreh
2021-07-26 22:37 ` divoplade
2021-07-27  0:15   ` EuAndreh
2021-07-30 14:59     ` EuAndreh
2021-08-04  1:54       ` EuAndreh
2021-07-27 15:22   ` Leo Famulari
2021-08-08 17:49     ` EuAndreh
2021-08-08 22:21       ` Leo Famulari
2021-08-09 13:41         ` EuAndreh
2021-08-09 16:35           ` Leo Famulari
2021-08-15 17:06         ` EuAndreh
2021-08-24 16:13           ` EuAndreh
2021-09-15 17:00             ` EuAndreh [this message]
2021-09-15 17:34     ` EuAndreh

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=163172525988.1171990.1918429373113497775@localhost \
    --to=eu@euandre.org \
    --cc=help-guix@gnu.org \
    --cc=leo@famulari.name \
    /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.
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).