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.
next prev parent 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).