You are not logged in.
Hello
for packages building content from a git repo, it seems that most PKGBUILDS download the whole repo, including the whole history, via https.
I also have seen specific tags or commits being downloaded with an source like
git://github.com/author/project.git#commit=24124214
However, this results as well in much more data being downloaded as required, in my case the tarball of the last release is ~300MB, while downloading the whole the repo is around 2-3 GB.
I saw an example for overcoming this limitation by downloading in prepare(), and storing the repo outside the srcdir:
https://aur.archlinux.org/cgit/aur.git/ … ja-ide-git
Is there an officially accepted way of using shallow clones?
Why are TUs relying on full clones?
Last edited by RoundCube (2018-10-18 01:04:14)
Offline
Been brought up and rejected many, many times. So some research.
Offline
We will NEVER add support for that. You can download the source using --depth=1 in the prepare() function.
and
It seems even when they (users) have a choice pointed out to them, they still can't choose. So I treat all users like idiots.
https://ugjka.net
"It is easier to fool people, than to convince them that they've been fooled" ~ Dr. Andrea Love
Offline
I saw an example for overcoming this limitation by downloading in prepare(), and storing the repo outside the srcdir:
https://aur.archlinux.org/cgit/aur.git/ … ja-ide-git
This package is so wrong, and it's not even doing shallow clones either. This is a relict of the boilerplate used before the PKGBUILD format supported git sources, which means it's even older than pacman 4.1.0 (released in 2013). The author of this PKGBUILD should be *embarrassed* to release a brand-new package in 2018 like that.
Is there an officially accepted way of using shallow clones?
Why are TUs relying on full clones?
We consider it philosophically wrong to even want this, let alone do it.
You can set the SRCDEST variable in /etc/makepkg.conf to preserve the git history between builds, which means updating should be almost instantaneous rather than requiring 300MB per release tarball...
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thanks for the answers. It seems that I was looking for is a rather niche thing… I went with the prepare() method.
Will also try out the SRCDEST the next time I need it.
For the lined package, I found it on GitHub a while ago, rewrote it to current standards, should be fine now.
Last edited by RoundCube (2018-10-18 01:05:04)
Offline