[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can't serve a custom channel on a HTTPS repository
From: |
EuAndreh |
Subject: |
Re: Can't serve a custom channel on a HTTPS repository |
Date: |
Wed, 15 Sep 2021 14:00:59 -0300 |
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.
- Re: Can't serve a custom channel on a HTTPS repository,
EuAndreh <=